Sometimes you have a requirement to generate your C# class contracts from an existing WSDL document so they can be used by consumers. It might be that the customer simply wants to keep the existing service contract and in this case only the implementation needs to be developed.

The way to do this in .NET is to use the SVCUTIL.exe command-line tool that you get when you install Visual Studio. Most people will know about this tool for generating C# client proxy classes to handle the service invocations and marshalling of simple and complex data contracts from the client side. It can also handle generation of the C# service contracts – although not pretty and will need to be cleaned up afterwards.

Just to note, when I say C# above, the tool also supports VB.NET, you just need to pass in the /l:VB switch. It defaults to C#.

So to generate your concreate service contract from an existing WSDL you can use the following syntax:

svcutil /dconly myservice.wsdl

If you’re lucky you’ll get a single myservice.cs source code file that contains everything i.e. all data contracts and the service contracts that you need in order to implement your service. You’ll need to clean this up though as the tool makes a mess of creating these contracts. You’ll also get a .XML file that can be added to your web.config or app.config file as it specifies the address, bindings and contracts for your service. It takes the address from the WSDL document and applies it to the config file.

If you’re not so lucky, you might get an error similar to the following:

D:\Workspaces\Simon\Project_Foo\Trunk\Foo\Source\Artefacts\WSDL>svcutil myservice.wsdl
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 4.0.30319.1]
Copyright (c) Microsoft Corporation. All rights reserved.

Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Schema with target namespace ‘http://schemas.foo/Services/Foo/2009′ could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:com:foo:services:foo:function:2011']/wsdl:portType[@name='PortType']

Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='urn:com:foo:services:function:feature:2011']/wsdl:portType[@name='PortType']
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:com:foo:services:function:feature:2011']/wsdl:binding[@name='EndpointBinding']

Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='urn:com:foo:services:function:feature:2011']/wsdl:binding[@name='EndpointBinding']
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:com:foo:services:fucntion:feature:2011']/wsdl:service@name=’Service’]/wsdl:port@name=’EndpointPort’]

Generating files…
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata docu
ments did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assembl
ies. Verify that you passed all the metadata documents to the tool.

Warning: If you would like to generate data contracts from schemas make sure to
use the /dataContractOnly option.

Looking through the error, the first thing that comes to mind is it looks like the separate namespace being imported could not be found as per the following error message:

Schema with target namespace ‘http://schemas.foo/Services/Foo/2009′ could not be found

This might be the case if your WSDL document looks something like the following:

<wsdl:types>
<xs:schema>
<xs:import namespace=”http://schemas.foo.com/Services/Foo/2009&#8243; schemaLocation=”Context.xsd”/>
</xs:schema>
</wsdl:types>

You look at the above WSDL snippet and think, well Context.xsd is present in the same folder as the WSDL document to which I’m trying to generate a code contract, so why can’t SVCUTIL find it.

It can’t find it because it’s not looking for it. You have to supply SVCUTIL with all the dependent XSD files on the command-line with the name and location of the WSDL document file like the following, i.e.

SVCUTIL myservice.wsdl context.xsd

Once you execute that command, you’ll notice you’ll get a single C# file with the same name as the WSDL document (in this case myservice.cs) containing all the code required to implement the WSDL. This includes correctly decorated service contracts (interface) and the correctly decorated data contracts for use with WCF (Windows Communication Foundation). I admit it makes a mess of this but it’s a starting point and saves you a great deal of time especially if your data contracts are large and complex as often seen in SOA environments.