RE: XML Serialisation

A few data points from my old days working on this stuff.

Since contracts in the WCF world almost always look the same on the client and server, running svcutil on a wsdl document will generate an interface that you can implement in your code to run the service. Unfortunately, to actually run the service you also either need to add entries to your .config file or imperatively instantiate your ServiceHost. Svcutil generates the config for clients to connect to the service but that config may need to be tweaked to host the contract instead.

svcutil.exe is meant to support the generation of contracts that use WCF from Metadata (WSDL, XSD, WS-* etc...). In this light, svcutil.exe completely replaces wsdl.exe for service development in WCF but it doesn't completely replace xsd.exe because the Data cannot be used in every situation where the XmlSerializer was used in the past and because svcutil.exe is mainly meant for web service development not for serialization.

As stated below svcutil.exe supports both DataContract and XmlSerializer for Web Service development. You can explicitly make it use XmlSerializer with the /serializer:XmlSerializer flag.

Early CTPs of WCF had a tool called dc.exe which was the DataContract equivalent of xsd.exe. This functionality was combined into svcutil.exe and can be accessed using the /dconly flag. This only generates code for the Xml Schema data types so there's not really a point in passing it a WSDL document. The /dconly and the /serializer:XmlSerializer flags cannot be combined because that's effectively the functionality you get form xsd.exe today.

DataContract can be useful if you want to eventually be able to serialize to formats other than text XML (DataContractJsonSerializer will be coming in .Net 3.5).

-Hoop

From: public-xsd-databinding-request@w3.org [mailto:public-xsd-databinding-request@w3.org] On Behalf Of George Cowe
Sent: Monday, August 20, 2007 6:21 AM
To: Jonathan.Whiteside@exchange.co.uk
Cc: Web Services Adoption Working Group Discussion List.; public-xsd-databinding@w3.org
Subject: 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.