by thinktecture's
Christian Weyer
Version 0.6 - 2006/2/27
New Features in v0.6
Read this document to see a full list of all new
features that made it into the 0.6 release.
Fixes in v0.6
Read this document to see a list of all fixes that
made it into 0.6.
Known Issues
We will maintain a list of known issues here.
Contributions
Many thanks goes to the numberless testers. Thanks!
Feel free to leave any comments, flames, or rants
at our thinktecture
forums.
Download
2006/2/27 Version 0.6
Version 0.51 - 2005/8/12 - major bug fix release!
There has been a lot of buzz around contract-first Web
services design & development lately. Nearly everybody thinks
that it is a good thing, and that we finally should reach a
state where we all can live and breath it. But most people have
been complaining about the lack of tool support for the so
called 'first step':
- Design your contract's messages and interface
- Generate code from the contract
We from thinktecture are proud to present the next
version of our very successful and freely available WSCF (formerly
known as WsContractFirst).
This new version 0.51 now offers a
simple yet powerful WSDL Wizard that abstracts away all the
nitty-gritty details of WSDL and therefore does not give room
for making errors and wrong assumptions just by trying to use
and applying everything that can be done stated by the original
WSDL specification. Plus there are number of new items that
primarily made it into the tool based on customer feedback.
Thank you all.
Additionally, we are finally offering a command line
interface to the code generation engine (wscf.exe). WSCF can thus be
included in your batch scripts and/or build process.
Fixes in v0.51 (compared to v0.5)
Read this document to see a full list of all fixes that made
it into the 0.51 release.
New Features in v0.51 (compared to v0.4)
Enhanced Code Generation
- Data type
generation: WSCF now optionally strips out generated data
classes and puts them in their own file.
- Interfaces: WSCF
now generates a .NET interface instead of an abstract class.
This is extremely helpful if you want to separately host the
service interface and the service implementation.
E.g. if you
want to host the service implementation under Enterprise Services
(ES) and expose
a service interface for ES, one for WSE messaging and one
for ASMX. In this case you have to define a shared interface
that follows the same contract as the WSDL file.
- Enhanced
properties: WSCF now checks for null references when it
generates properties for private fields.
- Constructors: WSCF
now generates some default ctor code with all necessary
parameters for data classes.
- Collections: WSCF
now validates input parameters (i.e. nullity) for Add,
IndexOf, Insert, Remove, and Contains methods
-
Naming guidelines: WSCF uses Pascal casing for generated type
names, even if XSD types use Camel casing (applies to Document/literal[bare] WSDLs
only).
- Misc:
- Generated Web
Service methods throw NotImplementedException by
default.
- XML
documentation in
/description/schema/.../element/annotation/documentation
will be persisted in <summary> XML docs in code for
generated type.
- Web Service help &
doc page:
- WSCF now
provides a Web service help page that the user can use
when going to the .asmx endpoint with his browser. In
0.4 code generation just disabled this ‘documentation’
feature.
- The
documentation page provides the same test and
documentation features as the original one; but it
disallows calling ?wsdl on the endpoint.
- WSCF now optionally
generates a <service> element into the WSDL. This is for
interop reasons, primarily.
WSDL Wizard and Generation
Improvements
- WSDL
round-tripping: load wizard from an existing WSDL and being
able to add and remove operations et. al.
- Message
headers: an indefinite number of header elements per message
is now possible, not just one.
- Schemas:
including other additional schemas than the one initially
selected to start from is now implemented.
-
Operation inference: automatically infers operation names
from message type names based on string patterns.
Installation
- Uninstall any previous versions of WsContractFirst (WSCF).
- Install new WSCF 0.51.
- Run devenv.exe /setup
- Caution: Doing this will delete all
customizations you have made to Visual Studio .NET
command bars.
The command bars are rebuilt according to the loaded
add-ins and packages. Sorry for this inconvenience.
Documentation
Obvious bug fixes
-
Creation of
collection types generated a
collection for byte[].
This type is usually required to transport binary data
through ASMX interfaces such as image data.
-
Selecting the
WSDL location from the dropdown list didn't set a
required internal property in some cases, thus causing
problems during code generation.
-
Pasting the path
to a WSDL into the location dropdown list did not
function properly in all cases.
Known Issues
- VS.NET commands & command bars do not get cleaned up
properly after uninstallation of the Add-In.
- Highlighting more than one row on step 3 of the WSDL
Wizard and clicking “Remove operation” only deletes the
first highlighted row.
Contributions
Many thanks goes to the numberless testers. Thanks!
Feel free to leave any comments, flames, or rants
at our thinktecture
forums.
Download
2005/8/12 Version 0.51
Version 0.4 - 2004/12/06
(Download link at the end
of the article).
There has been a lot of buzz around contract-first Web
services design & development lately. Nearly everybody thinks
that it is a good thing, and that we finally should reach a
state where we all can live and breath it. But most people have
been complaining about the lack of tool support for the so
called 'first step':
- Design your contract's messages and interface
- Generate code from the contract
Our tool has been quite good at the last one of the two
points: code generation. But there always was a missing link to
how to design and model the contract effectively.
Now we from thinktecture are proud to present the next
version of our very successful and freely available WSCF (formerly
known as WsContractFirst). This new version 0.4 now offers a
simple yet powerful WSDL Wizard that abstracts away all the
nitty-gritty details of WSDL and therefore does not give room
for making errors and wrong assumptions just by trying to use
and applying everything that can be done stated by the original
WSDL specification.
Additionally, we are finally offering a command line
interface to the code generation engine (wscf.exe). WSCF can thus be
included in your batch scripts and/or build process.
New Features in v0.4 (compared to v0.3)
- WSDL creation wizard
- Abstracts away WSDL details.
- WSDL conforms to WS-I BP 1.0 recommendations.
- One portType per WSDL.
- One binding per WSDL.
- One header per message.
- No fault support.
- Documentation items.
- Right-click message .XSD file in VS.NET to start
wizard.
- No round-tripping, i.e. currently one-way WSDL
generation only.
- Command line interface (wscf.exe), for including the code
generation features in batch files or build environments.
- Intrinsic support for RPC/literal WSDL descriptions.
- Adds task list items for important steps to take care of
after code generation.
- Should run with VS.NET 2002.
Installation
- Uninstall any previous versions of WsContractFirst.
- Install new WSCF 0.4.
- Run devenv.exe /setup
- Caution: Doing this will delete all
customizations you have made to Visual Studio .NET
command bars.
The command bars are rebuilt according to the loaded
add-ins and packages. Sorry for this inconvenience.
Documentation
- There is a walktrough
document with a lot of screenshots that explains, based on a simple sample scenario,
all the steps necessary for successful contract-first design
and development with WSCF 0.4. A step-by-step guide to a new
Web services experience.
Obvious bug fixes
- Improved import mechanimsms for referenced WSDLs
and/or XSDs.
- You can now add multiple Web service proxy classes
with endpoint configuration when there is no default
endpoint specified.
Known Issues
- Some WSDL documentation items do not propagate
correctly to generated .NET code.
- VS.NET commands & command bars do not get cleaned up
properly after uninstallation of the Add-In.
Contributions
Many thanks goes to the numberless testers. Thanks!
Feel free to leave any comments, flames, or rants
here or
there.
Download
2004/12/06 Version 0.4
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
- 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):
When done, you will see this message when clicking the 'Generate'
button ...

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.