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