If you generate a WCF VB proxy that contains a DataContract type using svcutil.exe, calling a method that returns the type will always incorrectly return an uninitialized type. This works correctly for C#.

 John Stallo, a peer of mine, spent some time investigating this issue. Here's the resolution:

The problem is a namespace mismatch issue that involves the /Rootnamespace compiler switch (on by default in VB projects). 

 

The important line of code that svcutil generates with this switch is an explicit namespace argument for DataContractAttribute. (This information is usually pulled from the service’s WSDL – the namespace below is the default one that’s generated if a namespace isn’t explicitly specified on the data contract on the server side):

 

System.Runtime.Serialization.DataContractAttribute([Namespace]:="http://schemas.datacontract.org/2004/07/")>  _

    Partial Public Class DataContract1

 

Apparently svcutil.exe doesn’t generate the explicit namespace argument by default.  So when the generated proxy is added to a VB project, the Data Contract type now falls under the VB project’s root namespace (e.g. ConsoleApplication1.DataContract1).  Without the explicit namespace argument, WCF has trouble finding the Data Contract type at runtime because the project’s root namespace throws a spanner in the works, which is why you then end up with uninitialized fields.  This doesn’t repro with C# because C# projects don’t have an implied root namespace.

 

Workaround:

Run svcutil with the following switch: /namespace:*,MyNamespace

…where “MyNamespace” is the namespace of your choosing that you want the proxy to be generated in.

 

Note that this will not be an issue with the Service Reference feature that will be available in the Feburary CTP of Visual Studio Orcas.

Cheers,

Ali