Service Contract Generation

In the post on custom namespaces a few days ago, I used svcutil to generate the service WSDL and schema description. This use of svcutil is apparently not as well understood so I thought I'd give some more details.

The typical use of these programs is to generate the necessary client files, proxy code and configuration, from an existing service. Rather than generating the client files directly, the same programs can be used to save a copy of the service description. Having the service description decouples downloading the metadata from generating the client files. If you would normally use svcutil [service-address] to generate client files, then you would instead use svcutil /t:metadata [service-address] to generate the metadata files. The followup command would be to run svcutil *.wsdl *.xsd to collect all of the generated metadata files and create the client files.

Another option that exists is to run svcutil against local files rather than a running service. You'll get some of the metadata from svcutil /t:metadata [files]. However, this misses collecting information about the binding or the actual service class (as opposed to the service interface type). Processing this service description still gets you something similar but not entirely like the generated client files you would have gotten from the running service. The missing information can be supplied by a reference to the configuration. Using the /serviceName option with the name of the configuration section that defines the service, svcutil will be able to complete the service description. The configuration file that gets searched is the standard one based on the executable file name. It's important to remember that the service name is not actually the name of the service but rather the name of the service section in the configuration file.

Next time: Creating Sessions over HTTP

Comments

• Anonymous
  August 13, 2007
  Why can't UniqueId be serialized? Data contracts only have native support for a limited set of types.