WSDL.exe produces inconsistent proxy classes between machines against the same local WSDL files

Article ID: 968775 – Last Review: March 9, 2009 – Revision: 1.0

WSDL.exe produces inconsistent proxy classes between machines against the same local WSDL files

Source: Microsoft Support

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

Symptom

If you have a WSDL file that contains two different types with the same name but from different namespaces then you may get different proxy class code when running wsdl.exe against the WSDL file on different machines.

 

For example if you have a WSDL file that defines two classes named UniqueID_Type from two different namespaces like the example below where the first definition for the type UniqueID_Type is for the namespace of http://www.contoso.com/OTA/CommonTypes, then the second type UniqueID_Type is for the namespace http://www.contoso.com/IATA/SimpleTypes:

 

 

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema

           xmlns=http://www.contoso.com/OTA/CommonTypes                                                                                                 

           targetNamespace=http://www.contoso.com/OTA/CommonTypes

           elementFormDefault=qualified>

   <xs:complexType name=UniqueID_Type>

      <xs:sequence>

         <xs:element name=CompanyName type=xs:string minOccurs=0></xs:element>

      </xs:sequence>

   </xs:complexType>

</schema>

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema

           xmlns=http://www.contoso.com/IATA/SimpleTypes                                                                                                     

           targetNamespace=http://www.contoso.com/IATA/SimpleTypes

           elementFormDefault=qualified>

   <xs:complexType name=UniqueID_Type>

      <xs:sequence>

         <xs:element name=CompanyName type=xs:string minOccurs=0></xs:element>

      </xs:sequence>

   </xs:complexType>

</schema>

 

 

If you generate a proxy class using WSDL.exe on different machines you may get two different results. On one machine your proxy class may define these two types as follows:

 

 

    /// <remarks/>

    [System.CodeDom.Compiler.GeneratedCodeAttribute(wsdl, 2.0.50727.42)]

    [System.SerializableAttribute()]

    [System.Diagnostics.DebuggerStepThroughAttribute()]

    [System.ComponentModel.DesignerCategoryAttribute(code)]

    [System.Xml.Serialization.XmlTypeAttribute(Namespace=http://www.contoso.com/OTA/CommonTypes)]

    public partial class UniqueID_Type {

       

        private string companyNameField;

 

        /// <remarks/>

        public string CompanyName {

            get {

                return this.companyNameField;

            }

            set {

                this.companyNameField = value;

            }

        }

     }

 

    /// <remarks/>

    [System.CodeDom.Compiler.GeneratedCodeAttribute(wsdl, 2.0.50727.42)]

    [System.SerializableAttribute()]

    [System.Diagnostics.DebuggerStepThroughAttribute()]

    [System.ComponentModel.DesignerCategoryAttribute(code)]

    [System.Xml.Serialization.XmlTypeAttribute(TypeName=UniqueID_Type, Namespace=http://www.contoso.com/IATA/SimpleTypes)]

    public partial class UniqueID_Type1 {

       

        private string companyNameField;

 

        /// <remarks/>

        public string CompanyName {

            get {

                return this.companyNameField;

            }

            set {

                this.companyNameField = value;

            }

        }

     }

 

 

On the other machine you may see these reversed where UniqueID_Type is from http://www.contoso.com/IATA/SimpleTypes and UniqueID_Type1 is from http://www.contoso.com/OTA/CommonTypes namespace:

 

 

    /// <remarks/>

    [System.CodeDom.Compiler.GeneratedCodeAttribute(wsdl, 2.0.50727.42)]

    [System.SerializableAttribute()]

    [System.Diagnostics.DebuggerStepThroughAttribute()]

    [System.ComponentModel.DesignerCategoryAttribute(code)]

    [System.Xml.Serialization.XmlTypeAttribute(Namespace=http://www.contoso.com/IATA/SimpleTypes)]

    public partial class UniqueID_Type {

       

        private string companyNameField;

 

        /// <remarks/>

        public string CompanyName {

            get {

                return this.companyNameField;

            }

            set {

                this.companyNameField = value;

            }

        }

     }

 

    /// <remarks/>

    [System.CodeDom.Compiler.GeneratedCodeAttribute(wsdl, 2.0.50727.42)]

    [System.SerializableAttribute()]

    [System.Diagnostics.DebuggerStepThroughAttribute()]

    [System.ComponentModel.DesignerCategoryAttribute(code)]

    [System.Xml.Serialization.XmlTypeAttribute(TypeName=UniqueID_Type, Namespace=http://www.contoso.com/OTA/CommonTypes)]

    public partial class UniqueID_Type1 {

       

        private string companyNameField;

 

        /// <remarks/>

        public string CompanyName {

            get {

                return this.companyNameField;

            }

            set {

                this.companyNameField = value;

            }

        }

     }

Cause

There is a bug in the .NET Framework SDK tool WSDL.exe where the order that the types are processed is dependent upon the file path to the WSDL file. If you copy your WSDL file(s) to C: Project Files MyWsdls files on one machine and generate the proxy class file using WSDL.exe you may see different results like this than someone who copied the same WSDL file(s) to D: wwf webservices wsdl directory to create the proxy class also using wsdl.exe.

Resolution

To work around the problem make sure that you copy the WSDL files to the same directory on the two or more different machines in order to generate consistent proxy classes. For example have all your developers create a folder at C: MyWsdls and copy the WSDL file(s) to that directory on all the machines and then run WSDL.exe against the WSDL files found in that directory.

DISCLAIMER

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.


APPLIES TO
  • Microsoft .NET Framework 2.0
Keywords: 
kbnomt kbrapidpub KB968775

 

Microsoft Knowledge Base Article

This article contents is Microsoft Copyrighted material.
Microsoft Corporation. All rights reserved. Terms of Use | Trademarks


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

Leave a Reply

*
To prove that you're not a bot, enter this code
Anti-Spam Image