Question

I’ve been trying to give more information to the provider about the error I’m getting when trying to consume one of his WS.

They asked me to use wsdl.exe to execute the following command:

wsdl.exe /l:CS /protocol:SOAP /verbose /sharetypes https:example.com/?wsdl

I did it, and got:
Error: There was an error processing ‘https://example.oom?wsdl‘.
– There was an error downloading ‘https://example.com?wsdl‘.
– The request was aborted: Could not create SSL/TLS secure channel.

Thing is that I have a cert to navigate that “https://example.com?wsdl” and I think it’s properly installed.
When I try to go to that URL in IE I only need to select the cert from a list and give it a certain permission. Then the wsdl is displayed.
I asked my WS provider to tell me how can I tell the command: “use ssl. Use this cert”. They told me to ask my networking team, but I’ve got no such thing, so I asked google, and I found: 1) enable SSL/TLS (if that means go to: IE > Internet Options > Advanced > SSL/TLS enabled, I did it) and 2) check the cert is installed and available. Which I think it is.

Can anyone tell me what can I do?
How is it that the cert is installed, but the command can’t reach it?

Answer 1

Are you saying that you need to supply a client-side certificate to navigate to that web page? If that’s the case, I’m not sure you can use the wsdl.exe tool directly to connect to it.

But you don’t need to. Load the WSDL up in IE and save it as XML, then point wsdl.exe to the local copy of the file. The only difference in the output will be the default endpoint address embedded in the proxy class. You should be setting that value up at run-time anyway, but you can always just edit the auto-generated C# code and fix it. The actual service and data contracts and the implementation code will be exactly the same.

One caveat: if this WSDL is produced by WCF, you have some extra work to do. WCF produces a federated WSDL definition: often times there are a half-dozen or more separate XSD files that make up the whole WSDL definition. Typically, the connection-related information is found in one file, while the type information is pulled in from somewhere else using tags that look like this:

<wsdl:types>
  <xsd:schema targetNamespace="foo">
    <xsd:import schemaLocation="https://localhost/Foo.svc?xsd=xsd0" namespace="foo"/>
    <xsd:import schemaLocation="https://localhost/Foo.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
    <xsd:import schemaLocation="https://localhost/Foo.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Foo.Model"/>
    <xsd:import schemaLocation="https://localhost/Foo.svc?xsd=xsd3" namespace="http://schemas.datacontract.org/2004/07/System.Collections.ObjectModel"/>
  </xsd:schema>
</wsdl:types>

If that’s true, you will need to do two things to get the WSDL you need:

1. Download all of the files that are referenced; these will be either <?include> directives or <wsdl:import> tags found within the other XMLs file, which pull in a second one. You need to check each new file, as there are often second and third level imports. Put everything into one folder.
2. Edit all of those include references to remove the URLs and just use local file references.

Once that’s done, wsdl.exe should run fine. (In .NET 4.5 there is built-in support for flattening the WSDL file out dynamically, but until then you have to do it manually.)