Freigeben über

Making svcutil.exe and VisualBasic.Net play nice

  • Artikel

Ali Pasha has an interesting post about some issues you can run into when you use Visual Basic and svcutil.exe and I thought I'd write a post to shed some more light on the issue.

DataContract types are uniquely identified using a namespace qualified name (namespace uri and a name). This namespace uri is used as the targetNamespace in XSD schemas created for that DataContract.

If a namespace uri is not specified when a DataContract is created, one is automatically created based on the CLR namespace of the type and using the prefix "https://schemas.datacontract.org/2004/07/" . (If you do not place your types in a CLR namespace then just the prefix is used).

To keep generated code as clean as possible, the client code generator doesn't generate an explicit namespace declaration if it doesn't have to. The problem with this approach is that VB.NET projects can affect the namespace of types using a root namespace. In the abscence of an explicit namespace uri declaration, changing a types namespace will also change it's schema which will affect it's wire representation.

As Ali pointed out, using the /namespace option with svcutil will fix the issue because the types namespace no longer maps directly to the auto-generated namespace and the code generator will have to explicitly define the namespace uri. Another way to make sure this doesn't happen is to define a namespace uri explicitly on the server. This should also cause the client to generate an explicit namespace uri definition.

You can also work around this by not not using a root namespace in your poject.

Note: This issue does not apply to service contracts because the default namespace does not affect wire communications.

Comments