How do I set the schema version attribute in a "code first" scenario?

Question

Hi gurus

Using the constructor of the attribute DataContract I can set the schema attribute targetNamespace. I would like to be able to set the optional version attribute of xml schema as well. How can this be done?

If not possible using the DataContractSerializer, can it be done using the XmlSerializer? How?

I plan to signal the exact schema version (including minor version) using the version attribute of the schema, and only signal the major version via the namespace, hereby keeping minor versions (potentially) compatible and have major versions deliberately as breaking changes.

Thanks

Michael Brandt Lassen

Answer 1

hi,

I think this is the fragile way to enforce versioning. DataContractAttribute does not expose this property, svcutil does not care about the schema optional version attribute, the same goes for xsd.exe, so what ever you signal, it's not enforced by current the tool support.

you could of course do "contract first" instead of "code first" as you here imply, but svcutil nor xsd.exe cares about that optional attribute anyway.

signaling a breaking changes with this attribute is fragile design, you should go for best practices instead:

http://msdn.microsoft.com/en-us/library/ms733832.aspx

I mean you can signal a breaking changes with this attribute on paper, but in practice no breaking changes in code appears after proxy update and the exact opposite could also be the case, which tends to make the clients unhappy :).

/Allan

Answer 2

Hi Allan

Thank you for your answer.

I would agree to your point in case I was trying to signal breaking changes via the version attribute. I’m not however. Breaking (major versions) will be signaled via the targetNamespace like version 1 here:

http://schemas.MyDomain.com/MessageType/1

But for compatible minor versions I’ll keep the namespace constant. Which I guess is one possible better practice?

I would however like to signal the minor version like version 1.3, hence the idea to use the version attribute.

What do you say?

Thanks

Michael

Answer 3

hi Michael,

I see where you're going, the tedious part here is the optional schema version attribute is ignored in the WSDL. This is at the end of the day a soa governance thing, right. So when I browse to service xyz I can't actually tell if any minor non breaking changes was introduced since last time...and that is actually the point of a non breaking changes, clients are unaware (ignorance is a bliss :)), so it's strickly a service/schema governance issue, you want to explict signal something changed.

..... I surpose you could ... and I am just taking a swing here, you could create a custom attribute say SignalSchemaVersion which impl. the usual suspects like IWsdlExportExtension, IContractbehavior derived from Attribute class... then create a SchemaVersion custom attribute you would set in your DataContract. Upon metadata generation, you would look for the custom attribute SchemaVersion and then stuff the version number into the schema version attribute at runtime .

fx.

[ServiceContract(.....)]

[SignalSchemaVersion]

public interface IMyService

{

[OperationC...] 

void SaveTheWorld(PeaceMessage msg);

}

[DataContract(namesp....]

public class PeaceMessage

{

   [DataMember(IsReguired=false)]

   [SchemaVersion("1.3")

   public string ButterFly{get;set;}

  }

}

still tool support is not enforced.... I am not sure... I don't like it :)

2 cents,

Allan

Answer 4

Hi alan

Cool, thanks!

Michael