On a previous project (.Net 1.1 Web Services) I spent hours if not days manually removing all of the proxy generated types from the Visual Studio.NET generated proxy class in order to use my Data Transfer Objects on the client tier.  To the best of my knowledge, this was the only way to achieve this short of implementing an Assembler to convert teh proxy type to my real types.

WCF changes this by providing a mechanism to exclude the type information from the proxy class based on the types it knows about in advance.  Unfortunately it's not built into the IDE, but that's hardly a major disadvantage.

The key is in manually using svcutil.exe to generate your proxy classes as follows:

C:\Samples\WcfSerialization>svcutil.exe /out:WcfServiceProxy.cs /d:Schmu
rgon.WcfClient.Web /r:Schmurgon.Data.Contracts\Schmurgon.Data.Contracts\bin\debu
g\Schmurgon.Data.Contracts.dll http://localhost:5150/Schmurgon.WcfService.Host/S
ervice.svc?wsdl

The switches are:

/out: param is simply the name of the output proxy class.

/d: the directory in which to store the proxy class.

/r: the assembly containing the types that would otherwise be included in the proxy class

[none] the address of your WCF service.

Invoking the Proxy Class

After including the generated class into a client application, it can be used as expected:

WcfServiceClient client = new WcfServiceClient();
TestDto testDto = client.FindTest( 1 );

Serializing to ASP.NET Session State? No Problem

ASP.NET 1.1 and the web services team really should have communicated a little more during development.  I was forced to use the [Serializable] attribute, along with full blown implementations of ISerializable in order to get my Data Transfer Objects to serialize correctly across the wire, and into session state in a web application.  Because my Dto's implemented events on the property setters, the events used to fire out of order during serialization.

Thankfully, this has been fixed with WCF.  The above example works perfectly placing the retrieved object into session state, pulling it back out again and then sending it back over the wire.

This was achieved mosty due to the design decision to use the [ DataMember ] attribute on the private fields of the class.  In my opinion, this is a much better way of implementing serialization, because it guarantees that the object is essentially identical before and after serialization.  Using the public properties is fine if you don't have any logic contained within the getters or setters, but otherwise I'd stick with the application to private memers.