OK, here we go ... 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.
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: you choose. The
Add-In automatically determines the project's programming language and
accordingly generates source code (currently C# and VB.NET supported). The
tool's functionality can also be reached through a common menu item entry in
VS.NET's Tools menu.
The Add-In handles the import of external schemas and WSDLs better than
wsdl.exe. The code that makes the Add-In breathe is based on snippets of my
formerly released DynWSLib to dynamically call Web services at runtime
without 'any' knowledge of the WSDL beforehand (well, yes: this is somehow
contradictory to the 'Contract First' approach. But it is actually useful in
some verly limited uses 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 showed at PDC.

New features in 0.2 (download link at the end of the article):
a.. Adding to the service side stub code generation, it now adds an .asmx
default implementation (automatic WSDL generation disabled, obviously).
b.. The client side developer gets access to the raw SOAP message - either
as a byte[] or simply as a string.
c.. Do you hate that wsdl.exe and the Visual Studio .NET "Add Web
Reference ..." dialog always and only can produce public fields for members
in data classes (based on the XSD)?
This tool can optionally generate private fields with public property
wrappers.
d.. Dynamic vs. static URL reference (you can configure the Web service
endpoint URL either in App.config or Web.config).
e.. Serveral bug fixes and internal improvements
[url]http://weblogs.asp.net/cweyer/posts/39070.aspx[/url]

Cheers,
--
Christian Weyer
[Microsoft Regional Director, Germany]
[MVP ASP.NET & XML Web Services]

** XML Web Services: [url]http://www.xmlwebservices.cc/[/url]
** Weblog: [url]http://weblogs.asp.net/cweyer/[/url]