By default, if the programmer does not specify the DateTime kind, .NET WCF services will serialize and deserialize DateTime objects based on the local time zone.  What this means is that if you have a client entering information on the east coast (EST) and your server is in central time (CST), the DateTime values entered by the client will have their hour decremented by 1 when the data is deserialized at the server.

The reason why WCF behaves this way is because it thinks that the DateTime entered on the client is in local time.  As a result, when the value reaches the server, 11:00 AM client local time is converted to 10:00 AM because that is what the local time is on the server.

If this is not what is desired, specifying the kind of the DateTime value appears to alter the serialization/deserialization behavior.  Specifying what kind of date your value is will not alter the underlying value.

Unspecified - No conversion:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Unspecified)
Local - Time Zone conversions:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Local) 
UTC – No conversions:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Utc)

In VS 2008, there is a problem with reusing collection types when you configure a WCF service and wish to “Reuse types in all refrenced assemblies”.  If you want to pass collections around via your WCF service, a Visual Studio will create a proxy class for each collection type regardless whether your collection type is included within referenced assemblies or not.  I will show you how to bypass this shortcoming.

First, locate the Reference.svcmap file for the WCF service reference you are having problems with.  If you can’t see it, ensure your project  has “Show All Files” enabled.  If you open the Reference.svcmap, you’ll find that it is written in XML.  Locate the CollectionMappings node.  Within CollectionMappings, add your collection type so when you update your service reference, it recognizes it as a known type and will not generate a proxy class for you.  Hope this helps.

<CollectionMappings>
	<CollectionMapping TypeName="System.Collections.Generic.List`1" Category="List" />
	<CollectionMapping TypeName="WpfApplication1.Objects.MyCollection" Category="List" />
</CollectionMappings>

Fiddler is the tool of choice when it comes to inspecting WCF messages that utilize an HTTP transport.  In a previous post I mentioned that HTTP WCF messages should be in encoded in a binary format to decrease their size.  The problem you run into when encoding your WCF messages is that when Fiddler attempts to inspect an encoded message, it’s not in a readable format.  To resolve this limitation, you can download a free plug-in which will add an inspector to Fiddler to decode binary WCF message.  Using this new inspector, you can inspect binary encoded WCF messages freely from within Fiddler.

http://code.msdn.microsoft.com/wcfbinaryinspector

Silverlight 3 offers us some new features when it comes to WCF web services.  In Silverlight 2, BasicHttpBinding was the only supported binding.  This essentially encodes your serialized objects in clear text and sends them over an HTTP transport.  Because the objects were sent as clear text, the message size could get out-of-hand.  When sending data across HTTP/Internet, you obviously want to decrease the size as this will improve performance of your client application.  Silverlight 3 offers the ability to create custom bindings which support the ability to encode your WCF web service messages as a binary format.

Binary encoding offers some serious performance gains over text encoding.  Personally I’ve seen 30% – 40% reduction in message size between the server and client when binary encoding is enabled.  Keep in mind that binary encoding is a WCF-specific feature.  Therefore if you have heterogeneous technologies wanting to consume your service, you’ll need to stick with BasicHttpBinding.  Here is an example of how to enable binary encoding for your WCF service:

<bindings>
	<customBinding>
		<binding name="binaryHttpBinding">
			<binaryMessageEncoding />
			<httpTransport />
		</binding>
	</customBinding>
</bindings>
   
<endpoint address="" binding="customBinding" bindingConfiguration="binaryHttpBinding" contract="MyService" />