Identical types in separate web services

Question

I have a similar problem with this question . I have several web services that I consume with WCF, which all use types. The services themselves are written in Java, and I do not have access to them. Generic types have the same signatures, but svcutil.exe gives this error on startup:

 Error: There was a validation error on a schema generated during export: Source: Line: 8 Column: 3 Validation Error: The complexType 'http://MyServer.MyService:CommonType' has already been declared. 

With CommonType having the same signature in both consumed web services. This is how I call svcutil :

 svcutil.exe /o:GeneratedServices.cs /n:*,MyNamespace.Generated http://MyServer.MyService1?WSDL http://MyServer.MyService2?WSDL 

I know that wsdl.exe has the /mergeTypes flag that works for these services, but there are some options in svcutil.exe that I really would like to use. I have someone who shows that this is possible for me, however the backend also used .NET and WCF, and I did not succeed in supporting the Java server I use.

Answer 1

At first - are they exactly the same? In particular, SOAP namespaces must match (in addition to everything else). If they do not, then they are different (incompatible) types; you will need to use two different links (in different C # namespaces to avoid conflicts), and shift the data between the two types.

If the types are the same and they still don't work, you can use the / r switch with svcutil to use the types from the existing assembly. Try to use it once to get the first types (from only one of the URLs) - then compile this code into the assembly. Use svcutil for the second endpoint with the / r flag identifying the assembly you created a few minutes ago.

Note; a related topic is to write a partial class for one or more types - for example, to provide conversion methods / operators for the types themselves. It can make things easier. For example, you can write an implicit (or explicit) static conversion operator between two similar types in different namespaces.

Answer 2

ANSWER PRINTED WITH PRINT (and context): And don't forget that svcutil.exe is just a tool. You can modify or extend the generated code - there is no prohibition there. Although, of course, there are flaws in customizing the generated code, and you should only do this with your eyes wide open.

In the early days, when I installed heterogeneous clients and servers together through web services, I regularly resorted to modifying the generated WSDL by changing the code generated from WSDL (I wrote many sed scripts to exchange namespaces when connecting AXIS and .NET) and others customized approaches. Some of the web services that were around the longest still require this. One example is the MS Office Research service, which does not send WSDL at all ...

Another approach, which may or may not work, is to extend the generated .NET code through partial classes. This is a great way to customize XML namespaces, add extra elements (like a version string?), And make other adjustments. And when you re-create the code, your extensions will not be overwritten.

EDIT: Judging from the top down, some people think this is too risky !!! I completely understand.

Answer 3

Since it exists in both services, then you get two ads after running svcutil for both services. I do not think svcutil.exe is smart enough to remake the same type in both web services.

You may need to manually delete the duplicate ad. If they are truly identical, then you can fix it so that you can use only one of them and eliminate the other.