In .NET 2.0 there is a great extensibility point for the wsdl.exe and xsd.exe called schema importer extension. By writing a class that inherits from SchemaImporterExtension and overrides the ImportSchemaType, you can affect how the tools generates the code. This is useful if you have created a class in your service that you want to share with the client too.
1 public class ContractsSchemaImporterExtension : SchemaImporterExtension
2 {
3 public override string ImportSchemaType(string name, string ns, XmlSchemaObject context, XmlSchemas schemas, XmlSchemaImporter importer, CodeCompileUnit compileUnit, CodeNamespace mainNamespace, CodeGenerationOptions options, CodeDomProvider codeProvider)
4 {
5 if (ns.StartsWith("MyNamespace"))
6 {
7 mainNamespace.Imports.Add(newCodeNamespaceImport("Company.MyDotNetNamespace"));
8
9 switch (name)
10 {
11 case "CreateUserRequest":
12 return typeof(CreateUserRequest).Name;
13
14
15 return base.ImportSchemaType(name, ns, context, schemas, importer, compileUnit, mainNamespace, options, codeProvider);
16 }
17 }
In the implementation you define how the incoming XSD types should map to the existing .NET types. In line 5 I start by checking that I recognizes the namespace and in that case adds the .NET namespace where my types exists. Of course this line will have to move into the case if the .NET types belongs to different .NET namespaces. In the switch I check the XSD types and returns the .NET type I want to represent it with.
To configure the tools to use the SchemaImporterExtension you have two choices; either to add a <schemaImporterExtension> element to the <system.xml.serialization> element in the machine.config file, or to supply a list of schema importer extensions via the /parameter option of the tools. Personally I prefer the first alternative because then I can use the tools through Visual Studio (in the Add Web Reference dialog for example).