Saturday, March 7, 2009

WCF DataContractSerializer changes in .NET Framework 3.5 SP1

I have been reading Michele Bustamante's Learning WCF. Its a very well-written book and the best part is that its written in a Tutorial style with plenty of labs to give hands-on experience otherwise it kind of gets boring to do plain reading. I am learning WCF on my own and not using it on a real project so I am finding this book to be very useful. This book was originally written for WCF released as part of .NET Framework 3.0 targeting Visual Studio 2005, there has been a reprint of the book as well as the accompanying code has been updated for .NET Framework 3.5 and Visual Studio 2008. With the ever changing world of technology, things get outdated pretty quickly hence I am also finding things here and there which have changed. Yesterday, I spent a few hours researching an issue related to DataContract where the code did not behave as expected so I thought I should write a quick post about my learning.


Let's look at a simple ServiceContract:

[ServiceContract] interface IEmployeeService
{
[OperationContract]
Employee GetEmployeeDetails(int employeeID);
}

The Employee class:
public class Employee
{
private int _ID;
private string _FirstName;
private string _LastName;
private string _Title;

public int ID
{
get {
return this._ID;
}

set {
this._ID = value;
}

}

public string FirstName {
get
{
return
this._FirstName;
}
set
{
this._FirstName = value;
}
}
public string LastName
{
get
{
return
this._LastName;
}
set
{
this._LastName = value;

}
}
public string Title
{
get
{
return
this._Title;
}
set
{
this._Title = value;
}
}
}

In versions prior to .NET Framework 3.5 SP1, an InvalidDataContractException was thrown if an attempt was made to host this service because WCF required any parameters/return types in the ServiceContract (other then simple types like int, decimal, string, etc.) to be explicitly marked serialiable either by using a DataContract or some other mean. Now, with .NET Framework 3.5 SP1 this is no more a requirement, any type not marked as seriailizable is by default serilized using DataContractSerializer. A few points to note about this default serializion for types:

  • The class must have a default constructor(parameterless constructor).
  • Only public read/write properties are serialized.
  • If the class is marked as DataContract then the normal rules apply i.e. only members marked with DataMember attribute are serialized.

One benefit resulting from this feature is that if you are exposing types defined in an existing assembly through WCF services, you don't need to make any changes to the existing type they will be automically be serialized for you whereas earlier there is was need to come up with a workaround like create surrogate types.
I was not able to find this change easily so thought I should write this post, hope this helps.

I have learnt quite a few other quirks related to WCF and LINQ and will be writing more posts as the time permits.

2 comments:

  1. good post

    Thank you.

    ReplyDelete
  2. Thanks for the Post, was working through the same lab in the Learning WCF book and was confused when it didn't throw the exception that the book said it would.

    ReplyDelete