CODEWITHSUNDEEP
c#soapwsdlsvcutil.exe
bakasan
bakasan

Reputation: 2302

/sharedtypes equivalent for svcutil.exe?

Building an app that is relying on a 3rd party provider who has a very verbose set of SOAP services (we're talking 50+ WSDL files). Each individual WSDL however has numerous shared type declarations. When generating client code with wsdl.exe, there used to be a /sharedtypes flag that would merge duplicate entries if a type was found several times.

When I attempt to generate my client code, I bomb on these overlapping types that the 3rd party includes in all their WSDL files.

svcutil /t:code /importxmltypes [mypath]/*.wsdl

Results in error messages alluding to the type collisions. For example, a couple samples of the error messages below:

Error: There was an error verifying some XML Schemas generated during export:
The simpleType 'http://common.soap.3rdparty.com:CurrencyNotation' has already been
declared.

Error: There was an error verifying some XML Schemas generated during export:
The complexType 'http://common.soap.3rdparty.com:NumberFormat' has already been 
declared.

I do not have control over the output of the WSDLs. I do not want to have to edit the WSDLs by hand for fear of an error that breaks in a fashion at runtime that would be highly difficult to track back to our editing of the WSDL files. Not to mention that there are 50 some WSDL files that range from 200-1200 lines of XML. (Remind me again why we thought SOAP was the great salvation to us all back in the late 90s?)

Upvotes: 16

Views: 4640

Answers (3)

user1310957
user1310957

Reputation:

I have been using wsdl.exe to get round this because I work with some SOAP webservices which define the same data transfer objects at different endpoints. So I use wsdl.exe because it has the sharetypes switch. I'm not a WPF developer so I don't really care that the output does not implement IWhatever for WPF, but the classes generated are all partial so you can do some work to implement interfaces you care about in a separate file.

Upvotes: 0

Daniel Jensen
Daniel Jensen

Reputation: 9

I was having similar problems. By defining different CLR namespaces for the different xml namespaces (using the /namespace argument of svcutil) i was able to get it working.

/namespace:http://www.opengis.net/gml,OpenGIS.GML

Upvotes: 0

Darin Dimitrov
Darin Dimitrov

Reputation: 1039418

Try specifying all the WSDLs in one command:

svcutil http://example.com/service1?wsdl http://example.com/service2?wsdl ...

This should automatically take care of duplicate types. Another option is to take a look at the /reference command switch:

/reference:<file path>        - Add the specified assembly to the set of
                                assemblies used for resolving type
                                references. If you are exporting or
                                validating a service that uses 3rd-party
                                extensions (Behaviors, Bindings and
                                BindingElements) registered in config use
                                this option to locate extension assemblies
                                that are not in the GAC.  (Short Form: /r)

This means that if you already have some types defined in some assembly you may include this assembly and svcutil will exclude types from it to avoid duplicates:

svcutil /reference:someassembly.dll http://example.com/service?wsdl

Upvotes: 2

Related Questions