A Rant of Sorts on Multiple .Net Web References

Written by Scott Balmos [Posted by Jack Vaughan]
I’ve got to admit, Visual Studio 2005 is a nice IDE. But when it comes to working with complex SOAP-based applications which have multiple endpoints and shared core, it can be a downright pain. I’m specifically referring to the Web References system, which transparently manages the annoyance of generating type stub and proxy classes from a WSDL file. It is, unfortunately, another classic case of Microsoft’s thought process behind trying to help developers work more efficiently - the common cases are very easy, but the hard things are very hard.

When it comes to Web Services, more and more systems are becoming increasingly complex. Many of them offer multiple endpoints - commonly one per major sub-application - while sharing a common core endpoint for initial authentication, session management, etc. Likewise, these endpoints share a common set of core datatypes, again usually a User, Session, and other such types. But trying to use these complex endpoints with Visual Studio is a downright pain. The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint.

No true explanation, nor any true answer to this dilemma has been given. The best I’ve seen are some people succumbing to the pain of manually changing the namespaces around in the auto-generated stub files. But that fix is short-lived, as the stub files are regenerated (separate namespaces and all) the next time the Web Reference is updated - a major pain for early-access developers to a web service whose WSDL file is still possibly in flux.

I don’t know about you, but I tend to see this as more and more of a thorn in the side of Visual Studio (and, by inference, .Net) developers as more complex SOAP services are built. For as much as Microsoft is trumpeting XML this and Web Services that, to believe that the Visual Studio and .Net groups didn’t seriously consider the use case of a complex service having multiple service endpoints is frustrating at best.

As I constantly continue building my one major JEE 5-based system (12 sub-applications and SOAP endpoints, with probably over 400 SOAP methods defined across those endpoints), and writing test SOAP clients in C#, I know I’ll be constantly bitten hard by this oversight. I’ll keep you updated if I find any more permanent answer, and let me know if you know of anything better.

I also, of course, welcome any vague ideas you may have for future blog entries. And I am not limited to SOAP/XML only, or specifically .Net and J2EE interoperability. In the coming weeks, I’ll be commenting on using J2EE systems with PHP, Ruby, and various other systems.

I’ll close off my blog entry with one of my favorite, and most poignant, lines from The Red Green Show (for you Canadians and Americans that watch PBS): “Remember, I’m pullin’ for ya… We’re all in this together”.

6 Responses to “A Rant of Sorts on Multiple .Net Web References”

  1. dovholuk Says:

    future blog suggestion:
    i’d personally like to see a blog entry around “polymorphism” and interoperability… are choice groups ok? substitution groups? abstract types?

    i personally abhor the first two methods preferring abstract types but i don’t know how the “abstract” keyword fits in with all the “other” programming languages (ie: not c based)

    what are the interop blog thoughts on thats subject?

  2. Matt Dunn Says:

    Hi Scott,

    This issue is resolved in .NET 2.0 with the introduction of the /sharetypes option for wsdl.exe (admittedly requires using the command line feature directly, not the Add Web Reference dialog in Visual Studio) heres an example of this feature: http://www.theserverside.net/tt/blogs/showblog.tss?id=WSStrikesBackP6

    Cheers,
    Matt

  3. Jimmy Says:

    Scott,
    It’s particularly ironic that you authored this post yesterday. As I leave this comment, my team is in the process of refactoring our common types so that they contain the ability to convert themselves from proxy generated common types to server side common types and vice versa. As of now, our common types are really just data structures. We are thinking of using reflection to negotiate the namespace on the proxy type. The structure of the type is known, so reflection is not necessary to populate the rest of the values. I’ll let you know how this turns out.

  4. Brett Bim Says:

    Regarding Matt’s suggestion, I’m not so sure that’s a resolution as much as it is a workaround. The supposed beauty of web references is that when (not if!) the reference changes, you can update it via Visual Studio and be on your way.

    We are currently experiencing the same pain from common types across services and are looking into making our common types more intelligent. They will be able, through reflection, to change themselves into the correct type for the correct service. Luckily, our common types are mostly dumb data structures so this is relatively straightforward. Maybe you could do something similar.

  5. Scott Balmos Says:

    Indeed, I have to agree with Brett that this is a workaround, not a solution. A solution would be a fix within Visual Studio itself. 

  6. Ryan Cromwell Says:

    Brett,
    I have to disagree. Matt’s suggestion is exactly the solution. As Scott says initially, the easy things are easy. Matt is showing the easy solution to a harder problem. Is it the easiest, no, but it’s definitely easier than manually aggregating WSDL’s and mucking with namespaces.

    Honestly, a simple batch file with 1 line per refernce would do everything “Web References” are doing for the simplest problem/solution.


Leave a Reply