Generated SforceService.cs file from enterprise.wsdl is enormous. How to condense?

I’ve generated a C# file with classes wrapping the Salesforce Enterprise API by downloading the enterprise.wsdl file from my organization’s Salesforce website to my PC, and running .Net’s wsdl.exe utility on it.

My issue is that the generated SforceService.cs file has 262000+ (!!!) lines of code!

All I need to do is be able to execute a single, simple SELECT Name FROM Account WHERE [critera] SOQL query. Committing a 200k+ line source file to my project just for this seems like significant overkill.

My question is: What’s the best way to go about reducing the SforceService.cs file to only what I need?

  • Should I manually remove some stuff from the enterprise.wsdl file before running wsdl.exe on it to generate the .cs file? If so, how can I determine what can be pared out? Is there documentation on this somewhere?


Salesforce provides two main WSDLs for accessing your orgs data via SOAP.

  1. Enterprise WSDL
    This is a strongly typed WSDL that is bound to the specific org it was generated from. It will have elements for every sObject and field that the generating user can access. Any changes to the schema in the org will require the WSDL to be generated again.
  2. Partner WSDL
    This is a loosely typed WSDL that can be used against any Salesforce Org. You can describe the meta data for sObjects and their fields and adapt as required. They only time you need to update it is if you want to access features from a new Salesforce release. Otherwise you can continue using it indefinitely.

So, the Partner API offers an immediate reduction to the WSDL size, especially if you are dealing with an org with a large number of sObjects and fields. It has other advantages to. If you add a new field to Salesforce, you can have the integrating code query the metadata to see if it is available yet. This makes staged deployments much easier.

If you still really want to use the Enterprise WSDL I have an idea that I haven’t tried in practice yet. As the generated WSDL will only expose the objects that the current user has access to, you could try restricting the Salesforce user to just the Account object. Then generate the Enterprise WSDL as that user before restoring the security settings.

Source : Link , Question Author : Jon Schneider , Answer Author : Daniel Ballinger

Leave a Comment