Service Reference in .net for Debug and Release

Question

I am writing a small program in .net (C#) which is connecting with Salesforce. I downloaded wsdl file from both production and sandbox environment.

What is the correct way of using the service reference for Debug and Release configurations? Should I import both references and use the corresponding one depending on selected configuration?

#if DEBUG
using WebApi.Salesforce_DEV;
#else
using WebApi.SalesForce_PRO;
#endif

Or is the preferred way just to change the endpoint url for each configuration?

Thank you

Answer 1

The Enterprise WSDL is strongly typed and specific to the org it was generated from. If there is the slightest difference in the Metadata between the production and the sandbox org they will get differing WSDLs (beyond the SOAP endpoint).

Unless both your production and sandbox orgs have metadata that is permanently fixed I'd probably recommend going with the Partner API, which is loosely typed. It is more effort up front without the strong typing, but it gives you the flexibility to handle metadata/schema changes.

---

Lets go through an example of adding a new custom field that is on an sObject that you work with via the API.

With the Enterprise API, once you make the change in the sandbox to add the new field you will need to update your code to the new sandbox WSDL. Make any required changes for the new field, rebuild the code, and deploy the updates so it can work with that Sandbox. However, that new fields Metadata hasn't been deployed to the production org yet. You won't be able to deploy that branch of the code base until production gets updated to match the sandbox. Better still, when production is updated you will need to do a coordinated push of the C# code at the same time.

Compare that to the Partner API. When the need field is added to the sandbox you don't necessarily need to do anything to the C# code. There is no need to update the WSDL as it can already show you the new field details via the describe metadata calls. When you are ready, you can code and deploy the changes to work with the new field in the sandbox. Better yet, you can deploy that code all the way to production before the new field even exists there. You use the describe calls to detect the presence of the field and adapt accordingly.

The flexibility that the Partner API gives you requires more effort, but I believe it is worth it for any real world scenario where you are going to need to support changes to the org over time.