OK, you may have realized that WSCF is a side-project these days - mostly due to the fact that we are deeply involved in very interesting projects in the service-orientation and workflow space. But now we found some free time to integrate the most wanted feature into 0.7:
Right-click on an .XSD in VS 2005 and generate .NET (data transfer object) code from it (with support also in the command line tool).
For this, I would need three thorough testers! Please get in touch with me via the Contact form and we will figure out how you could help us (please keep in mind that you would need to really test WSCF 0.7 against all the XSD you have and give immediate feedback).
We are just finishing 0.5 of WSCF and try to figure out the feature set for 0.6 already.
One thing we want to add is a visualization component for WSDL interface descriptions - because a picture tells more than a thousand words. And everybody should be able to grok the e.g. Google WSDL more easily when looking at an (interactive) graphical representation instead of staring at angle brackets.
Here is our question: which kind of diagram do you think would be most appropriate to visualize a WSDL inside Visual Studio .NET (i.e. the essence of WSDL, not every single detail of WSDL - but this should be an obvious fact)? You can leave your comments here or contact us directly - and maybe send in some hand drawings ;)
Improved WSDL Wizard - Various enhancements -We enabled WSDL round-tripping: loading the wizard from an existing WSDL and being able to add and remove operations et. al. I.e. you can now visually edit your service interface description safely inside the WS-I boundaries. Currently only supports WSDLs we have created through WSCF.
-We can now have any number of headers for a given message, not just one, which is the limitation in WSCF 0.4. -We can now import additional XSD files, not just the one initially selected to start from in the IDE.
Enhanced code generation - ASMX Web Service help & doc page We now provide a working Web Service help page that the user can use when going to the .asmx endpoint with his browser. Currently we just disable this ‘documentation’ feature. This documentation page provides the same test and documentation features as the original one; but it intrinsically disallows calling ‘?wsdl’ on the endpoint (returning a 404). Because we start from the WSDL we do not want to have the WSDL available through the endpoint (although it would be possible technically).
Enhanced code generation - Misc improvements -Enhanced properties: we now check for null references when we generate properties for private fields. -Constructors: we now generate some default ctor code for data classes so that you can set up your DTOs with one single line. -Collections: we now validate input parameters (i.e. nullity) for Add, IndexOf, Insert, Remove, and Contains. -Generated Web Service methods throw NotImplementedException by default. -XML documentation in /description/schema/.../element/annotation/documentation will be persisted in "<remarks>" XML docs in code for generated type.
Enhanced WSDL generation - Adding <service> element for better interop We now optionally generate a <service> element into the WSDL. Actually, we think that we just should create a 'service-less' WSDL as an abstract interface description. And indeed, the service element is spec-wise not needed. But Mr. Interop discovered several problems when testing WSCF-generated WSDLs with some Java stacks. So this is for interop reasons, primarily.
Enhanced code generation - Interfaces We now generate a .NET interface instead of an abstract class with all the (unnecessary and duplicated) ASMX attribute glue. 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 COM+ and expose a service interface for Enterprise Services, 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.Voilà. Additionally, we also generate an interface for the consumer-side proxy. You may imagine that this easily enables scenarios where the proxy generation/instantiation can be done by a configurable factory. By doing so, the location and the chosen transport can be hidden. It's then even possible to cache proxies.