RE: XML Serialisation

Thanks Jonathan.

 

Re WCF/.NET 3.0 Contract First (WSDL) Web service generation.

 

Further to the information you provided below I also found some more on the subject.

 

This thread from the MSDN forum describes the problem.  

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1989063&SiteID=1

It looks like the old wsdl.exe and xsd.exe command line utilities (available in .NET 2.0) have been replaced by a new utility called svcutil.exe (in .NET 3.0). Wsdl.exe and xsd.exe still ship with .NET 3.0 but will only produce .NET 2.0 compliant code. For contract first web service generation you must use the svcutil.exe utility in .NET 3.0.  

 

Someone has fed back the issue to Microsoft

https://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=124245

 

The issue over which serialization implementation to use is also discussed here 

http://blogs.msdn.com/sonuarora/archive/2007/06/16/contract-generation-from-wsdl-xml-schema-datacontractserializer-vs-xmlserializer.aspx

where it looks as if the .NET 3.0 svcutil.exe utility will use the XmlSerializer as opposed to the DataContractSerializer when a WSDL(or a schema within a WSDL) uses a complex schema structure like xsd:choice or xsd:attribute. 

 

So the bottom line is that WCF can still provide contract first web services but you must use a different method of achieving it. However I haven't tried it yet, but will do and I'll keep you posted.    

 

George

 

 

From: Jonathan.Whiteside@exchange.co.uk [mailto:Jonathan.Whiteside@exchange.co.uk] 
Sent: 20 August 2007 11:33
To: George Cowe
Subject: FW: XML Serialisation

 

George,

 

As discussed.

 

Regards,

 

Jonathan

 

**************

 

This article has some good background on the two serializers.

 

Comparing ASP.NET Web Services to WCF Based on Development <http://msdn2.microsoft.com/EN-US/library/aa738737.aspx> 

 

Basically .Net 2.0 uses the XmlSerializer, WCF by default uses the DataContractSerializer hence the differences in classes generated from an xsd. 

 

The different serializers have different rules that determine what they do with the different type definitions in the xsd.

 

I've taken the detail below from the article.

 

"The following is a list of key issues to know about when defining .NET Framework classes that the XmlSerializer will be able to serialize to and from XML: 

*	Only the public fields and properties of .NET Framework objects will be translated into XML.
*	Instances of collection classes can be serialized into XML only if the classes implement either the IEnumerable <http://msdn2.microsoft.com/EN-US/library/system.collections.ienumerable.aspx>  or ICollection <http://msdn2.microsoft.com/EN-US/library/system.collections.icollection.aspx>  interface.
*	Classes that implement the IDictionary <http://msdn2.microsoft.com/EN-US/library/system.collections.idictionary.aspx>  interface, like Hashtable <http://msdn2.microsoft.com/EN-US/library/system.collections.hashtable.aspx> , cannot be serialized into XML.
*	The great many attribute types in the System.Xml.Serialization <http://msdn2.microsoft.com/EN-US/library/system.xml.serialization.aspx>  namespace can be added to a .NET Framework class and its members to control exactly how instances of the class are represented in XML.

 

The following is a list of the important differences between using the DataContractSerializer and using the XmlSerializer and the various attributes of the System.Xml.Serialization namespace

 

*	The XmlSerializer and the attributes of the System.Xml.Serialization namespace are designed to allow you to map .NET Framework types to any valid type defined in XML Schema, and so they provide for very precise control over how a type is represented in XML. The DataContractSerializer, DataContractAttribute and DataMemberAttribute provide very little control over how a type is represented in XML. You can only specify the namespaces and names used to represent the type and its fields or properties in
the XML, and the sequence in which the fields and properties appear in the XML: 

[DataContract( Namespace="urn:Contoso:2006:January:29", Name="LineItem")] public class LineItem { [DataMember(Name="ItemNumber",IsRequired=true,Order=0)] public string itemNumber; [DataMember(Name="Quantity",IsRequired=false,Order = 1)] public decimal quantity; [DataMember(Name="Price",IsRequired=false,Order = 2)] public decimal unitPrice; }

Everything else about the structure of the XML used to represent the .NET type is determined by the DataContractSerializer. 

*	By not permitting much control over how a type is to be represented in XML, the serialization process becomes highly predictable for the DataContractSerializer, and, thereby, more amenable to optimization. A practical benefit of the design of the DataContractSerializer is better performance, approximately ten percent better performance. 
*	The attributes for use with the XmlSerializer do not indicate which fields or properties of the type will be serialized into XML, whereas the DataMemberAttribute for use with the DataContractSerializer shows explicitly which fields or properties will be serialized. Therefore, data contracts are explicit contracts about the structure of the data that an application is to send and receive.
*	The XmlSerializer can only translate the public members of a .NET object into XML, the DataContractSerializer can translate the members of objects into XML regardless of the access modifiers of those members.
*	As a consequence of being able to serialize the non-public members of types into XML, the DataContractSerializer has fewer restrictions on the variety of .NET types that it can serialize into XML. In particular, it can translate into XML types like Hashtable that implement the IDictionary interface. The DataContractSerializer is much more likely to be able to serialize the instances of any pre-existing .NET type into XML without one having to either modify the definition of the type or develop a
wrapper for it. 
*	Another consequence of the DataContractSerializer being able to access the non-public members of a type is that requires full trust, whereas the XmlSerializer does not. The Full Trust code access permission give complete access to all resources on a machine that can be access using the credentials under which the code is executing. This options should be used with care as fully trusted code will have access to all resources on your machine.
*	The DataContractSerializer incorporates some support for versioning.

	*	The DataMemberAttribute has an IsRequired <http://msdn2.microsoft.com/EN-US/library/system.runtime.serialization.datamemberattribute.isrequired.aspx>  property that can be assigned a value of false for members that are added to new versions of a data contract that were not present in earlier versions, thereby allowing applications with the newer version of the contract to be able to process earlier versions. 
	*	By having a data contract implement the simple IExtensibleDataObject <http://msdn2.microsoft.com/EN-US/library/system.runtime.serialization.iextensibledataobject.aspx>  interface, one can allow the DataContractSerializer to pass members defined in newer versions of a data contract through applications with earlier versions of the contract.

 

Despite all of the differences, the XML into which the XmlSerializer will serialize a type by default is semantically identical to the XML into which the DataContractSerializer will serialize a type, provided the namespace for the XML is explicitly defined"

========================================================================================================================Vertex Disclaimer
 
The information contained in this email is intended only for the
individual to whom it is addressed. It may contain privileged and
confidential information. If you have received this message in
error or there are any problems, please notify the sender immediately
and delete the message from your computer. The unauthorised use,
disclosure, copying or alteration of this message is forbidden.
Neither Vertex Data Science Limited nor any of its subsidiaries
will be liable for direct, special, indirect or consequential damage
as a result of any virus being passed on, or arising from alteration
of the contents of this message by a third party. The following
Vertex companies are authorised and regulated by the Financial
Services Authority: 
 
-       Vertex Data Science Limited (registered in England and Wales
with registered company number  3153391)
-       Exchange FS Limited (registered in England and Wales with
registered company number 2596452) trading as The Exchange 
-       Vertex Mortgage Services Limited (registered in England and
Wales with registered company number  2042968)
-       Vertex Administration Limited (registered in England and
Wales with registered company number  2138853)
-        Jessop Fund Managers Limited  (registered in England and
Wales with registered company number 5768993).
  
All the above companies have their registered office Pegasus House,
Kings Business Park, Liverpool Road, Prescot, Merseyside, L34 1PJ
 
 
www.vertex.co.uk
========================================================================================================================


E-mail disclaimer

The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.

Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents.  It is your responsibility to scan for viruses.  Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control.  When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited.  If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender.  The contents of this e-mail are protected by copyright.  All rights reserved.

Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 4th floor, Saltire Court, 20 Castle Terrace, Edinburgh EH1 2EN.