I pointed out the difference. In .NET when you generate a proxy for the web service using add web reference, classes are created that contains the objects that are returned and passed to the web service and a class that you use to make the web service calls (SforceService).

When you use the enterprise wsdl, classes are created for each data object (accounts, contacts, leads etc.). These are defined essentially by the schema that is visible to the logged in user when the wsdl was generated. All salesforce.com account will have objects and fields on those objects in common. The standard objects and standard fields on those objects will be common to all. If the application you are creating is only using standard objects and standard fields, then you can use the enterprise wsdl.

The partner wsdl only contains one data object which is the SObject. All other object are cast from and to an sobject. This provides more flexibility in creating a solution that is cross instance. In other words, you can do declarative control of the data. For example, the sforce explorer allows you to enter a SOQL statement for any object using any fields (custom or standard) and works for everybody. The reason is the data is late bound to the ui and there are no concrete class with a fixed shape to contain the results. When the records are returned from the query they are in the more generic SObject class which contains basically key value pairs for the fields. These key value pairs are iterated and columns for a datatable created from the results. If you used an enterprise wsdl as the basis for this, then if the user included a custom field in the SOQL statement, .NET would complain that the data won't fit into the precompiled definition for the object.

What is you application going to do? Maybe I could provide a little direction as to how best to implement it.