Neue Features in WSCF 0.5:
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. for 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)
- Generated Web Service methods throw NotImplementedException by default.
- XML documentation in /description/schema/.../element/annotation/documentation will be persisted in
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
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.
[via Christian Weyer]