1

I have a single self-contained (third party) WSDL file with say 10 operations. (server is not .net) All operations have their own XML namespaces defined for operations, messages and all the underlying types.

Some of the underlying types in different operations have same names and sometimes same content or same structure (not always) as well but they are actually different as they are defined in different xml/xsd namespaces (so they are unique).

When I import this WSDL into my c# client project, I can give it one unique namespace in the VS porject and it generates the proxy/stub. The problem is wherever the different operations have same (xml type) names for the underlying types then it generates the c# class names like: MyType1, MyType2...

Additionally the third party server, can update the service and so the WSDL is updated and the underlying types are generated again into .net classes like MyType1, MyType2... but this time, maybe previously generated MyType6 is generated as MyType7 and this breaks the client/consumer code.

What solution exists to address this problem?

We are thinking to customize the wscfblue code but it seem to be a cumbersome work and would require maintenance..

Environment:
-VS2013 Ultimate (Client)
-.net 4.5 (Client)
-Unknown technology (Server) -> generates WSDL and provides the endpoint.
hB0
  • 1,977
  • 1
  • 27
  • 33

1 Answers1

0

You can generate the proxy using svcutil.exe and provide mappings from xml namespaces to CLR namespaces with /n. It also supports multiple mappings, which it sounds like you need.

Example: use svcutil to map multiple namespaces for generating wcf service proxies

Community
  • 1
  • 1
moarboilerplate
  • 1,633
  • 9
  • 23
  • Thanks but it did not work for me. As its also mentioned in the answer over there "I am currently having trouble where the types generated from .xsd files are not affected by these namespaces" - it did not created the separate namespaces and the all the types are created like MyType1, MyType2.. – hB0 Dec 15 '14 at 15:43
  • Looking at the comments on [this answer](http://stackoverflow.com/questions/6849580/svcutil-from-wsdl-file-error-schema-with-target-namespace-could-not-be-found) it seems you might be in luck if you don't use *.xsd but explicitly name all of the xsd files in the command line. If you are still having problems after that, you might be stuck having to resort to a custom solution. – moarboilerplate Dec 15 '14 at 22:38
  • I have all those methods and combinations of command-lines and it does not work at all. svcutil is no good for multiple namespaces when you have one service contract and data contracts are coming from various XSD files with unique xml namespaces (and worsens if the types in different xml-namespaces have the same names). – hB0 Dec 16 '14 at 13:00
  • The only other possible solution I can think of would be to run xsd.exe separately for your XSD files, provide namespaces accordingly, and replace your svcutil-generated types with those. Since adding a service reference through visual studio and svcutil.exe (wsdl.exe is pretty much an older version of the same thing) are pretty much the only out-of-the-box WCF solutions for creating a client proxy, I'm afraid you may be out of options unless you create your own serialization code. – moarboilerplate Dec 17 '14 at 15:28