Odd .Net serialization issue

Question

I had a strange problem today when I was trying to serialize an object. The object was created using the "Add Service Link" from the web service (svcutil.exe).

The problem was that the below property (agencyId) was not serialized with the rest of the object. Out of desperation, I commented on the property below because it had "XMLIgnoreAttribute" assigned ... after I commented on the ignored property, the agencyId field was serialized as expected.

Can someone explain to me why this happened? Thanks!!

/// <remarks/> [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified, Order=1)] public string agencyId { get { return this.agencyIdField; } set { this.agencyIdField = value; this.RaisePropertyChanged("agencyId"); } } /// <remarks/> [System.Xml.Serialization.XmlIgnoreAttribute()] public bool agencyIdSpecified { get { return this.agencyIdFieldSpecified; } set { this.agencyIdFieldSpecified = value; this.RaisePropertyChanged("agencyIdSpecified"); } } 

Answer 1

There is a pattern (for XmlSerializer) that the Foo property will also look for either "bool FooSpecified" or "bool ShouldSerializeFoo ()" - and if it is found, only serialize Foo if this other member returns true. So, I believe that the IDSpecified agency has never been set to the truth? Removing this member will always make it serialized (unless you add [DefaultValue] or the like).

This type of behavior is used to model optional values ​​in the case when we really need to know if it was in the source data, i.e. does it have a value of 0 because the caller told us that number or because it is simply the default.

Note that the “FooSpecified” member usually has [XmlIgnore] , so the XmlSerializer knows that it cannot be considered as data for serialization. This is optional (or legal) with "ShouldSerializeFoo ()", as methods are never serialized.

Answer 2

The purpose of the XmlIgnoreAttribute is to tell the XmlSerializer that you do not want to serialize this property: it is an integer point. So you see, this is the developed behavior of this code. A much better question is why the class developer decided to decorate this property in this way.