The Web services empire strikes back - Code generation: properties instead of fields

Part 1: The Web services empire strikes back - Introductory thoughts
Part 2: The Web services empire strikes back - Inner Workings
Part 3: The Web services empire strikes back - Web Services in Visual Studio 2005
Part 4: The Web services empire strikes back - WS-I BP Conformance
Part 5: The Web services empire strikes back - Custom XML Serialization
Part 6: The Web services empire strikes back - Proxy Type Sharing
Part 7: The Web services empire strikes back - Contract-first with .NET `IDL`
Part 8: The Web services empire strikes back - Schema Importer Extensions
Part 9: The Web services empire strikes back - Making asynchronous Web service calls easier
Part 10: The Web services empire strikes back - Support for Nullable and SqlTypes
Part 11: The Web services empire strikes back - Support for Generics
Part 12: The Web services empire strikes back - Web services and large content [link]

A small but nice and very powerful new feature is intrinsic to the proxy generation process, again. I cannot count the number of emails and newsgroups postings I have read and answered regarding this problem. The standard proxy generation process in the 1.x version of the .NET Framework always emits public fields for complex types found in the services message contracts data structures. This is of course a big disadvantage, at least when it comes to data binding have you ever tried to bind Windows Forms controls to public data fields

Version 2 now automatically and by default generates private fields encapsulated by public properties. This is a big win. The following code listing is the OrderStatusInfo class we have been talking a few times in former posts.

[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(
  Namespace="http://www.thinktecture.com/demos/Orders")]
public class OrderStatusInfo {
   
    private int orderNumberField;
   
    private System.DateTime orderDateField;
   
    private System.DateTime shipDateField;
   
    ///
    public int OrderNumber {
        get {
            return this.orderNumberField;
        }
        set {
            this.orderNumberField = value;
        }
    }
   
    ///
    public System.DateTime OrderDate {
        get {
            return this.orderDateField;
        }
        set {
            this.orderDateField = value;
        }
    }
   
    ///
    public System.DateTime ShipDate {
        get {
            return this.shipDateField;
        }
        set {
            this.shipDateField = value;
        }
    }

Finally we have the desired behavior that makes data binding a breeze. And for those of you paying attention to the above code, you might have realized an additional attribute that can save a lot of people a lot of work: System.SerializableAttribute. This means that now by default our types are not only XML serializable by using the XmlSerializer but also runtime serializable by using one of the runtime formatters like SoapFormatter or BinaryFormatter.

To sum up all the new and important switches of wsdl.exe that have been introduced in this short overview, you can take a look at the following table.

Switch

sqltypes

sharetypes

verbose

fields

Table: Important wsdl.exe switches

BTW, if you want or need those features, i.e. public fields and [Serializable] types - already with .NET 1.x you can try the WSCF tool.