testing - How can you use two WSDLs and maintain a test instance with a C# application?

Question

I have created a service that communicates with the SalesForce platform via C#, using their WSDL. It so happens that SalesForce (rather logically) allows for "sandbox" instances of its platform and "production" instances of its platform. My application is designed to work with production, but I have been using the sandbox to integration test and unit test. I am now reaching the point where I need to deploy to production. However, I face a large problem in that if I ever need to build and test new features, I will have to update the WSDL from the production instance to the sandbox instance, then swap back and forth as I add new features. This is because the two WSDLs are entirely different and I have to generate code from them! This is not only sloppy, it's dangerous. I could affect some of my live system data.

I would like to find a way to use a registry key, a text value, or some configuration setting that tells my application which WSDL to use. Trouble is? I can't figure out how one could approach that. The very objects my code is referencing are generated from that WSDL. Any ideas?

Answer 1

WSDLs shouldn't be entirely different between the two! Of course unless a lot of new objects and custom fields has been created in the sandbox and not yet pushed to production...

Is there any chance you've mixed the enterprise (strongly typed version) and partner (more generic one) WSDLs? Check this help topic for more info: http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_quickstart_intro.htm#choose_wsdl

If you're truly concerned about data model you might decide to use partner version (generated code is bit ugly then because it gives you generic sObjects instead of more specific Account, Contact etc). I was always fine with enterprise version (the stuff from sandboxes eventually made it up to production and once different systems started to rely on the data model teams just started to sync their releases if possible).

---

Way to distinguish them that worked for me was to examine the endpoints (at the very bottom of the file). I was doing PHP integrations so for me it wasn't a problem to flip the endpoint on the fly but "trust" the same object structure. No idea how it looks like in C# world, where does this piece of information end up in the parsed code... Good luck!

Enterprise - Sandbox

<service name="SforceService">
<documentation>Sforce SOAP API</documentation>
<port binding="tns:SoapBinding" name="Soap">
    <soap:address location="https://test.salesforce.com/services/Soap/c/26.0/(18 char sandbox Id)"/>
</port>
</service>

Enterprise - Production

https://login.salesforce.com/services/Soap/c/26.0/(prod id)

Partner WSDLs have "u" in the URL instead of "c" and they don't carry specific organisation's id: https://test.salesforce.com/services/Soap/u/26.0"/

(my small trick to memorize this is to think about it as "Client" or "Customized" and "Universal")

Edit: of course if you'll stick to "enterprise" the only endpoint you can really count on is production. Sandbox org ids change every time they're refreshed.