7

I'm attempting to use svcutil.exe to generate -only- the service contracts (interfaces) from a set of .wsdl files. When I do this (from an http-hosted wsdl), it picks up the included schemas and generates all the code for them.

Great.

What I would REALLY like to do, however, is to use a set of classes already generated from the schema files using the xsd.exe tool (the reasons for this are not important, suffice it to say that I need to have the types in one assembly, and the service contracts in another). I was successful in generating an assembly containing all the types.

The problem occurs when I attempt to get svcutil.exe to use the types in that assembly. My command line looks something like this:

svcutil /target:code /noconfig /reference:my_types.dll http://path/to/wsdl

This works fine, but the generated code contains duplicates of all the types in the my_types.dll file. It is my understanding from the documentation for svcutil.exe that this is the exact problem that the /reference: parameter is meant to overcome. In my case, however, it is not working.

Why?

Mark
  • 11,257
  • 11
  • 61
  • 97

2 Answers2

5

Apparently it only works for DataContract types and not XmlSerializer types.

Link

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Andrew
  • 1,696
  • 2
  • 16
  • 20
  • That seems to be exactly the reason. I wish he'd gone into more detail on why this limitation exists, but thanks for the answer nonetheless! – Mark Oct 25 '10 at 14:52
  • Have you tried manually running WSDL.exe against your WSDL to generate a proxy class. Delete the classes it generates then add the references to your classes. – Andrew Oct 25 '10 at 16:37
1

I had this problem. Something in a binary that I was referencing with /r was still being built again in the generated code. One of the objects being returned from one of the service functions was returning a datatable or some other horrid thing like that. I added a /r to the whole path to System.Data and that fixed it.

/r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Data.dll"

David Osborne
  • 31
  • 4