Thursday, November 13, 2003

WSDL.EXE Replacement Sought

I'm running smack into two big limitations of WSDL.EXE,
the tool used to generate client-side proxies for web services in .NET. Specifically,
here are the problems:

1) WSDL.EXE relies on the same code as XSD.EXE to map
the XML types into programmatic types. Unfortunately, it generates types with public
fields rather than properties. This prohibits data binding. I'd like to change this.

2) If you run WSDL.EXE against two different WSDL documents with exactly the same
XSD type in them, it generates two programmatic types. That is <foo/> turns
into NamespaceA.Foo and NamespaceB.Foo. This is a problem if you want to read a Foo
from web service A and pass it to web service B.

Neither of these problems are insurmountable. The problem
is the solutions aren't elegant. Better than either would be for someone to tell me,
"Hey, you just need to download SuperWsdl.exe; it does everything you need." Unfortunately,
I'm not sure SuperWsdl.exe exists. I'd prefer not to write it myself.

Anyone got any advice? Leave a comment.


  1. Atif Asiz wrote a replacement as part of his VSNET Code Generator Shim project:
    It handles problem 1 for you, but I don't think it handles problem 2. Also, it's packaged as a custom tool - don't know if it's callable from the command line.

    One thing that I didn't like about Atif's solution is that it doesn't act as a drop-in replacement for Microsoft's custom tool. It uses it's own XML file, which means no "Add Web Reference" support in VS.NET. So I started writing my own version, which does let you use "Add Web Reference". It's basically working, but I've been so busy with work I have had a chance to clean it up and release it yet. Hopefully I'll get around to it some day soon. Again, it only solves problem 1, though. I haven't really considered problem 2 yet - I'll think about it.

  2. Oh, the other tool that I've encountered in this space is this:

    But I haven't run it yet, so I don't know if addresses your issues specifically.

  3. As Kevin already menioned, I have a very early and raw version of a tool you might be interested in : WsContractFirst. I am open to all good suggestions ...

  4. As Kevin already menioned, I have a very early and raw version of a tool you might be interested in : WsContractFirst. I am open to all good suggestions ...

  5. Comments on VSCodeGenerator: it doesn't even seem to handle problem #1 as far as I can tell. The one relevant sample I found uses the same code as WSDL (ServiceDescriptionImporter) and generates the same propertyless classes.

    Haven't checked out Christian's code yet.

  6. I believe there's an attribute that you need to set to enable property generation ("privateFields"). You can look at the source in WebServiceClientGenerator.cs.

    It does use ServiceDescriptionImporter, but then goes through and converts the fields to properties. My generator works the same way.

  7. For #1, The approach I have used is to build shims at runtime for databinding. (via CodeDom) Example:

    Also I saw an article on this same technique recently (I forget the URL, tho)

  8. Yes - I see it now. Thanks - this has given me some major food for thought.

  9. The field/property thing is one of those "what were they thinking" impedance mismatches in the framework. I blogged a question about this with Whidbey, and ScottGu responded that they've fixed it, thank goodness. Don't know about the type-sharing issue, though.

  10. I had heard a rumor that it was fixed in v1.1 if you ran both wsdl files through wsdl.exe at the same time, but it's not working for me. That may be due to the fact that for my specific case I have types in two namespaces and a resulting xs:import. I haven't tried putting everything in the same XML namespace yet.

  11. I just updated my code with the basic idea from the VSNET Code Generator Shim project to solve #1 (there were some flaws in there. Hopefully my code is working as suggested). If you like to test it I would be happy to receive an email from any of you.
    Just ping me at c w _AT_ e y e s o f t . d e


  12. The start of the problem is uses such as my self writing in vb but that not important) who don't have nor want the Microsoft envirement. As my problem is with eBay and it seems to work under the microsoft editer system my guese is that the system does not run WSDL.exe, but its own(fixed) code. What I and others need therfore must be stand alone(and .exe).



  13. Umm, WSCF *is* an EXE. Go check it out.