WsContractFirst

A Visual Studio .NET Add-In for improved “Contract First” Web services development.

by thinktecture's Christian Weyer

Version 0.3 - 2004/08/30

(Download link at the end of the article):

Maybe some of you know that I am a big believer in contract-based Web services design and development. Web services contracts can be expressed explicitly in .NET code or by using schema (XSD) and WSDL. When using the second approach you may want a tool that can generate .NET code from your WSDLs/XSDs. The .NET Framework's and Visual Studio .NET's intrinsic tools somehow don't cut it, sorry.So, did you ever want to simply right-click on a WSDL file in Visual Studio .NET and generate code from that Web service contract?

Now you can - whether it be a client-side proxy class or a server-side stub skeleton, you choose. Our add-in for Visual Studio .NET 2003 automatically determines the project's programming language and accordingly generates source code (currently C# and VB.NET are supported).

New Features in v0.3 (compared to v0.2):

  • More 'intuitive' GUI (e.g. default button, tooltips on controls etc.) - well at least for an angle brackets guy ... :)
    • If you right-click on a WSDL file in project you can choose 'Generate Web service Code...'
       
    • If you right-click on a project you can choose 'Choose WSDL to implement...'


       
    • And then there is still the Tools menu item 'Web service Contract-First...'


       
  • Can add an external WSDL to the project and generate code based on it. Just enter the URI of the WSDL into the textbox
    • via HTTP
    • via file system
  • Can mark classes as [Serializable]
  • Can generate collection-based members instead of arrays
  • Comment propagation from WSDL into proxy classes
  • Can enable automatic validation of incoming SOAP messages on service side (by using a custom SoapExtension)
  • Saves configuration form settings
  • A few bug fixes

This is the dialog you will be presented when choosing one of the above described options to enter the contract-first path in VS.NET:

This is the description of each option in the configuration dialog (from left to right, top to down):

  • The location of the Web service message and interface contract (WSDL). Can be a URL or file location.
  • Enable this if you want to generate consumer-side proxy code to consume a Web service based on the WSDL.
  • Enable this if you want to generate code for a service-side Web service facade based on the WSDL.
  • Check this to get public properties in your data classes instead of public fields.
  • Check this to get runtime serializable data classes.
  • Generates collection-based members instead of arrays.
  • Check this to enable Web service endpoint configuration in a .config file.
  • Check this to get read-only access to the actual SOAP message in your client code.
  • Enables XSD-based validation on incoming SOAP messages
  • Please enter the name of .NET proxy file that gets generated.
  • Please enter the name of .NET namespace for the client proxy.
  • Please enter the name of .NET service facade file that gets generated.
  • Please enter the name of .NET namespace for the service code.
  • Save dialog settings for future use.

When done, you will see this message when clicking the 'Generate' button ...

Feel free to leave any comments, flames, or rants here. Special thanks to all testers (too many to list here ;)).

Version 0.2 - 2003/11/21

New features in 0.2

  • Adding to the service-side stub-code generation, 0.2 now adds an .asmx default implementation (automatic WSDL generation disabled, obviously)

  • The client-side developer gets access to the raw SOAP message -- either as a byte or simply as a string

  • Do you hate that wsdl.exe and the Visual Studio .NET "Add Web Reference ..." dialog only produce public fields for members in data classes (based on the XSD)? This tool can generate private fields with public-property wrappers.

  • Dynamic vs. static URL reference (you can configure the Web Service endpoint URL either in App.config or Web.config)

  • Serveral bug fixes and internal improvements

The Long Story
I am happy to announce version 0.2 of a tool -- a Visual Studio .NET Add-In -- called WsContractFirst. The first bits (version 0.1) already have made it through the blogosphere and rumbled in Web Services town. Nice.
Microsoft obviously did not have enough time to add a little feature to their prime IDE. So I had fun getting to know the beloved and still COM-based extensibility model of Visual Studio .NET.

I know, I know, a lot of people will rant that it is just the GUI-ified version of wsdl.exe. Well, no. It is a completely new write-up. I am not leveraging wsdl.exe through the command line but using the .NET framework classes directly. So the code is completely extensible. I plan to publish the code a little later, and I may turn the whole thing into a GotDotNet Workspaces project.

So what does it do, dude?
Ever wanted to simply right-click on a WSDL file in Visual Studio .NET and generate code from that Web Service contract? Now you can -- whether it be a client-side proxy class or a server-side stub skeleton. The Add-In automatically determines the project's programming language and generates source code (currently C# and VB.NET supported). The tool's functionality can also be accessed through a common menu item entry in VS.NET's Tools menu.

The Add-In handles the import of external schemata and WSDLs better than wsdl.exe. The code that makes the Add-In breathe is based on snippets of my previously released DynWSLib. It calls Web Services at run time without any knowledge of the WSDL beforehand. (I admit, this is somewhat contradictory to the “Contract First” approach. But it is useful in some very limited cases, such as testing. Actually, the lib is used in a client-side service invocation factory in a .NET-based Grid computing project.) BTW, it would be nice if the server-side stub code would not produce an abstract class, but an interface instead -- just what Indigo is capable of, as Don showed at PDC.

  

This is the second step in my and others’ vision of first designing the Web Services contract (and policy!) and then generating code skeletons from that. Hmm … Maybe there are some guys out there who can help me with the first step of visually designing the contract ... Chris, where are you?

TODO:

  • Testing, testing, testing (could need your help here)

  • Adding desired features from users (well, need your help here, too :-))

  • Make it more sexy ...?

Feel free to leave any comments, flames, or rants here or there.
Special thanks for testing, ideas, and comments to Tomas, Pierre, Christoph, Ralf, Klaus and Scott - and let's not forget Yasser. Thanks, guys.

Download

2004/09/01 Version 0.3 (Version 0.3 of 2004/08/30 with the XML comments bugfix of 2004/09/01)
2003/11/21 Version 0.2


DISCLAIMER:
The sample is provided as is. It is only a sample; it does not in any way conform to coding guidelines, and it has not been proved to be a stable product! The code has not been reviewed by third parties or even been refactored for optimization. There is still plenty of room for improvement.
Though the author accepts no responsibility for any damage or inconveniences caused by this sample, he is willing to accept questions and comments about it. Please note also that this code is only a technology demo and should not be included unedited in any serious project.