Missing namespace in the WSDL.exe element when using .NET 2.0 /parameters switch
I have just fixed a bug in the docs in which the xml namespace is left out of the topic for WSDL.exe when using the /parameters switch. The <wsdlParameters> element must have the namespace, so it must be:
<wsdlParameters xmlns="https://microsoft.com/webReference/">
and the documentation should look like the following:
/parameters
Read command-line options from the specified xml file. Use this option to pass the Wsdl.exe tool a large number of options atone time. Short form is '/par:'. Option elements are contained inside a <wsdlParameters xmlns=" https://microsoft.com/webReference/ "> element. For details, see the Remarks section.
And the examples should read:
The /parameters option specifies a file that contains elements that correspond to most of the command-prompt options. Some command-prompt options are available only in the /parameters file formats.
The XML file format accepted by the /parameters option is a series of elements inside an outer <wsdlParameters xmlns=" https://microsoft.com/webReference/ "> element. If command-prompt values are specified and a /parameters file is used that contains different options or values, the values specified at the command prompt are used. The <wsdlParameters xmlns=" https://microsoft.com/webReference/ "> element must contain a <nologo> element, a <parsableerrors> element, and a <sharetypes> element.
The following example code shows a basic /parameters WSDL file with only the required elements written that can be used combined with a URL argument at the command prompt.
<wsdlParameters xmlns="https://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
</wsdlParameters>WSDL documents are added in the /parameters WSDL file using the <documents> element, as the following code example demonstrates. Any number of <document> elements can be used inside the <documents> element.
<wsdlParameters xmlns="https://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
<documents>
<document>https://www.contoso.com/service.asmx?WSDL</document>
</documents>
</wsdlParameters>The following /parameters WSDL file demonstrates the use of the <codeGenerationOptions> and <style> elements inside the <webReferenceOptions> element. In this case, the file enables the new style of databinding in proxy code, and specifies a schema importer extension, that output is not to be verbose, and that Wsdl.exe is to create a client proxy.
<wsdlParameters xmlns="https://microsoft.com/webReference/">
<nologo>true</nologo>
<parsableerrors>true</parsableerrors>
<sharetypes>true</sharetypes>
<documents>
<document>https://www.contoso.com/service.asmx?WSDL</document>
</documents>
<webReferenceOptions>
<verbose>false</verbose>
<codeGenerationOptions>properties newAsync enableDataBinding</codeGenerationOptions>
<schemaImporterExtension>
<type>MyNamespace.MyCustomImporterExtension,ExtensionLibrary</type>
</schemaImporterExtensions>
<style>client</style>
</webReferenceOptions>
</wsdlParameters>
Comments
- Anonymous
March 11, 2006
This is great information.
In the <type> element, where will wsdl.exe look for th extension object? - Anonymous
March 27, 2006
This is very helpful.
I have the same query however.
Where does wsdl.exe look for the type? <type>MyNamespace.MyCustomImporterExtension,ExtensionLibrary</type> - Anonymous
November 22, 2010
The comment has been removed