Coffeehouse Post

Single Post Permalink

View Thread: .Net versioning question
  • User profile image

    I'm not a web services expert so I have the following question...

    Let's say I have a web service that exposes its API via WSDL. Also say I created proxy classes in a DLL from that WSDL that now allows me to interact with the web service. Next, a new version of the web service is released and hence I need to generate a new DLL from that WSDL. None of the previous methods or any of the previous types have changed, only new methods and types were added.

    Here is the problem... My client application needs to be able to connect to either version of the web service, because some servers will still be using the older version. More importantly, it needs to be able to connect to one, disconnect, and then reconnect to a different version.

    So what I'm doing right now is I put the proxy classes for each version inside its own namespace. So I have a namespace SomeApi10, and another one SomeApi20. Then whenever I need to call into the web service, I do either

    if (version == 1)

    This is not ideal because in most cases the code is more complex and I need to duplicate large blocks of code to handle multiple calls to the correct API version, including dealing with different types defined by each different API (even though the method and type names themselves are identical).

    What I'm looking for is a way to prevent this code duplication (and future-proof the code so that the next version doesn't require me to create yet another code path). I want to be able to put both proxy versions into the same namespace, but have some other way to specifiy which DLL version should be used. I know I can subscribe to the "Resolve" events but this will only help me on during the 1st load, as it is not possible (or very difficult) to unload a DLL again.

    BTW, these APIs are exceedingly complex, with over 7500 calls, and a huge amount of types. It is not possible to simply wrap it with another class (which would still require the multiple code paths internally).

    Any suggestions?