Freigeben über

Technical Note: Proxy Classes Different when using Svcutil.exe and VS Add Service Reference (doubleclick.com edition)

  • Artikel

The WSDL url https://advertisersapi.doubleclick.net/v1.12/api/dfa-api/campaign?wsdl was used by a customer with the Svcutil.exe tool to generate a proxy class and associated message and data classes, and it worked fine. But when they tried to use the Add Service Reference... (often shortened to "ASR") wizard in Visual Studio, they had a problem: they could not import the fault contracts. In fact, even with Svcutil.exe, there was a warning generated due to the tool's inability to understand the WSDL:

Warning: Fault named ApiException in operation copyCampaigns cannot be imported.
Unsupported WSDL, the fault message part must reference an element. This fault
message does not reference an element. If you have edit access to the WSDL docum
ent, you can fix the problem by referencing a schema element using the 'element'
attribute.

In any case, the difference between ASR and Svcutil.exe is that one has the UseSerializerForFaults option easily available to you as a switch on the command line. Using this switch instructs Svcutil.exe to use the XmlSerializer to handle faults instead of the default, which is the DataContractSerializer. In this case, although Svcutil.exe has indicated that the WSDL for the fault is flawed, it continues to import the service operation. If you want to enable VS ASR to do the same thing:

  1. Click Show All Files in the Solution Explorer.
  2. Open the Reference.svcmap file in your service reference.
  3. Set the option <UseSerializerForFaults> to false in Reference.svcmap and save it. (NOTE: Take care NOT to update the service reference, as doing so resets the option to true.)
  4. Open the reference.cs and you should see the operations generated.

 The WSDL for the fault contract will still need to be modified before the tools can generate the fault contract propery, but at least you can get your service proxies generated. Hope this helps. It's part of a larger series of issues revolving around this area. For one view, see https://dotnetbutchering.blogspot.com/2010/03/add-service-reference-duplicates.html, which points out a bug that **may** have been fixed in a more recent version of the .NET Framework -- or may not. I'll try to find out tomorrow.