SvcUtil Essentials: Generate Proxy from Compiled Code

25. July 2007 07:13

This the next post in my short series on some of the highlights of svcutil.  Last time, I posted about the command used to generate a proxy and corresponding configuration by referencing a service that is currently running.  While useful, there will be occasions where you need to generate a proxy when the service is not running.  In those situations, another option could be using the compiled assembly that contains the service implementation to generate the proxy. 

Unfortunately, there is no single command that can be used to generate a proxy by only pointing at an existing assembly.  The process has to be broken down into two steps.

  1. Export metadata from the complied code.
  2. Use the metadata to generate a proxy.

Assume you have a complied assembly, MyServiceAssembly.dll, that contains the implementation of a WCF service.  You need to extract the metadata of the service from the compiled code.  Once the metadata has been made available, svcutil can generate a proxy in almost the same manner as a service that is running.

Export Metadata

So, how do you get the metadata out of a compiled assembly? 

svcutil /t:metadata MyServiceAssembly.dll

This command will search the assembly and export the service metadata.  It will create a WSDL file and any XSD files that are referenced by the WSDL.  To the best of my knowledge, you do not have any control over the name of the output files via svcutil.  The utility will use the namespace of the service specified in the ServiceOperationAttribute.  If no namespace has been specified, the default value of will be applied.

Generate Proxy with Metadata Files

Now that you have the WSDL and corresponding XSDs, a proxy can be generated using nearly the same command as when the source is a running service.

svcutil /t:code *.wsdl *.xsd /out:Proxy.cs /config:Proxy.config

If you refer to the previous post about generating a proxy from a running service, you will find the only difference to be specifying the wildcard pattern for the WSDL and XSD files.  In this case, the utility will search for WSDL and XSD files on the local machine in the given directory.  It should be noted that you are not required to use the wildcard pattern.  You can specifically list each individual file as part of the command.  This is just a slightly shorter variation if you only have the applicable files in the given directory.


Now you have a proxy and metadata that is ready for distribution without having a running service to generate the files.

Comments are closed

About Me

I'm a passionate software developer and advocate of the Microsoft .NET platform.  In my opinion, software development is a craft that necessitates a conscious effort to continually improve your skills rather than falling into the trap of complacency.  I was also awarded as a Microsoft MVP in Connected Systems in 2008, 2009, and 2010.

Can’t code withoutThe best C# & VB.NET refactoring plugin for Visual Studio
Follow jeff_barnes on Twitter

View Jeff Barnes's profile on LinkedIn


Shared Items


Anything you read or see on this site is solely based on my own thoughts.  The material on this site does not necessarily reflect the views of my employer or anyone else.  In other words, I don't speak for anyone other than myself.  So, don't assume I am the official spokesperson for anyone.