views:

365

answers:

2

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?)

A: 

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
Darin Dimitrov
All the wsdls are local, but that's beside the point. My problem isn't that I'm not able to pass in several .wsdl files. The problem is that the source has included multiple datatypes in every single wsdl file (or several, if not all). For example, browsing through, of the first 6 wsdls I've opened, it appears 5 have a ComplexElement entry for a type called CurrencyNotation. When svcutil tries to parse all my wsdls, it says, oh hey, currencyNotation already exists, SO SORRY. BOOM.
bakasan
So you're saying that individually typing out each wsdl path will behave differently than going *.wsdl (all the wsdls reside locally). As this is the first generation of our proxies, I really don't have an assembly to reference in. Would a strategy be to parse one wsdl, compile to a dll, then reference it for the next one? Resolve dupes, then rinse and repeat for the rest?
bakasan
Wasn't quite ready to type out the paths to all 50+ wsdl files, but testing w/ just two, svcutil foo.wsdl bar.wsdl bombed out w/ the same duplicate types message. After having dealt w/ pains from wsdl.exe years ago, it's not very comforting to see that svcutil.exe in this day and age doesn't appear much better. :P
bakasan
A: 

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
Daniel Jensen