Share via


Code Changes After Conforming Web Service Endpoints to WSDL Files

After you conform an implemented Web service endpoint to a Web Services Description Language (WSDL) file, there might be changes in the following code files associated with the endpoint:

  • The file that implements the Web service class.

    This class contains operation signatures and any method body code. An operation is a class method with the WebMethod attribute and other related attributes.

    Note

    No method body code changes when you conform an implemented endpoint. However, the changes described in this topic might cause method body code to no longer compile. Therefore, review your code and identify changes that might be required to fix any compiler errors.

  • One or more class files that contain custom type definitions.

Changes might include the following:

  • Adding new operation signatures

  • Updating operation signatures

  • Removing WebMethod attributes from operation signatures

  • Updating operation attributes

  • Adding or renaming custom type definitions

  • Conforming only the first matching operations

  • Adding comments about changes to code files

The Web Service Details window will also reflect the appropriate changes. The following sections contain more information about these changes.

Adding New Operation Signatures

If the WSDL file describes a new operation, Visual Studio adds that operation's signature and attributes to the Web service class. You can identify this new operation signature by looking for the WebMethod attribute. 

Note

Class methods without the WebMethod attribute are non-Web methods, not operations. Such methods are not included when comparing operations. For more information, see Updating Operation Signatures.

The new operation's MessageName parameter will match the operation's name in the WSDL file. You can find the MessageName parameter in the WebMethod attribute of the operation's signature.

Note

The new operation might have the same name as an existing class member (excluding non-Web methods). In this case, Visual Studio adds an ordinal to the new operation's method name, making it unique.

For example, suppose the Web service class contains a member named "newCatalog". If the WSDL file describes an operation named "newCatalog", the operation's method name appears as "newCatalog2" in that class. The following lines show the result after conforming to this WSDL file:

[Visual Basic]
Public newCatalog As String

'''<remarks> [UserName::Date] This Web method was added after conforming this service to the WSDL file. </remarks>
<System.Web.Services.WebMethod(MessageName="newCatalog")> _
<System.Web.Services.Protocols.SoapDocumentMethod(Binding:="MyWebService")> _
Public Sub getCatalog2()
...
End Sub

[Visual C#]
public string newCatalog;

/// <remarks> [UserName::Date] This Web method was added after conforming this service to the WSDL file. </remarks>
[System.Web.Services.WebMethod(MessageName="newCatalog"), System.Web.Services.Protocols.SoapDocumentMethod(Binding = "MyWebService")]
public string newCatalog2()
{...}

Updating Operation Signatures

If the WSDL file describes an operation that matches an operation in the Web service class, Visual Studio updates the operation signature and its attributes in the class. The following list describes criteria used to match operations between the Web service class and the WSDL file. Examples showing these criteria compare class code to a WSDL operation named "getCatalog" (with the same message name): 

  • A class operation "matches" if it has the same message name, but not the same method name as the WSDL operation.

    Note

    The MessageName attribute identifies the operation's message name.

    For example, the following class operation matches the "getCatalog" WSDL operation:

    [System.Web.Services.WebMethod(MessageName = "getCatalog")]
    public void getNewCatalog()
    
  • A class operation "matches" if it has no message name, but has the same method name as the WSDL operation.

    For example, the following class operation matches the "getCatalog" WSDL operation:

    [System.Web.Services.WebMethod()]
    public void getCatalog()
    
  • A class operation does not "match" if it has the same method name, but a different message name as the WSDL operation.

    For example, the following class operation does not match the "getCatalog" WSDL operation:

    [System.Web.Services.WebMethod(MessageName = "getGolfCatalog")]
    public void getCatalog()
    
  • A class method is not considered an operation if it has the same method name, but does not have a WebMethod attribute. This method is left unchanged. Instead, a new operation signature and the corresponding attributes are added to the class.

    For example, the following class method does not match the "getCatalog" WSDL operation because it lacks a WebMethod attribute and is left unchanged:

    public void getCatalog()
    

Removing WebMethod attributes from Operation Signatures

If the Web service class implements an operation not described in the WSDL file, Visual Studio removes the WebMethod attribute and other corresponding attributes from that operation in the class. The operation changes to a non-Web method.

For example, the following lines show an operation with its WebMethod attribute and other corresponding attributes before it conforms to a WSDL file:

[Visual Basic]
<System.Web.Services.WebMethod()> _
<System.Web.Services.Protocols.SoapDocumentMethod(Binding:="myWebService")> _
Public Sub getCatalog()
...
End Sub

[Visual C#]
[System.Web.Services.WebMethod(), System.Web.Services.Protocols.SoapDocumentMethod(Binding = "myWebService")]
public void getCatalog()
{...}

The following lines show how the operation loses the WebMethod attribute and other attributes after it conforms to a WSDL file that no longer describes this operation. The operation becomes a non-Web method:

[Visual Basic]
''' <remarks>[UserName::Date] The WebMethod attribute was removed after conforming this service to the WSDL file. This operation does not exist under the corresponding port type in the WSDL file. </remarks>
Public Sub getCatalog()
...
End Sub

[Visual C#]
/// <remarks>[UserName::Date] The WebMethod attribute was removed after conforming this service to the WSDL file. This operation does not exist under the corresponding port type in the WSDL file. </remarks>
public void getCatalog() 
{...}

Updating Web Service and Operation Attributes

If the attributes of the Web service class or operations do not match the WSDL file, Visual Studio updates them in the class. For example:

  • The Web service name and namespace might be updated.

    If the service name and namespace in the class are not the same as those in the WSDL file, Visual Studio updates them. Visual Studio updates these values in the class as part of the WebServiceBinding attribute.

  • Each operation binding name is updated.

    If each operation's binding name in the class is not the same as that in the WSDL file, Visual Studio updates the binding name. It updates this value in the class as part of each operation's SoapDocumentMethod attribute.

The following list contains other attributes that might be updated:

  • WebMethod

  • WebService

  • SoapDocumentService

  • SoapRpcMethod

  • SoapRpcService

Any user-added attributes will not be changed.

Adding or Renaming Custom Type Definitions

Operation signatures added from a WSDL file might reference custom types. Once the associated application is implemented, one or more class files might appear in your solution. These files contain the corresponding type definitions. Their file names use the following format:

"<ServiceName><CustomTypeName>.<FileExtension>"

Note

The file extension depends on the implementation language.

In these files, the namespaces containing these type definitions use the following format:

Namespace <DefaultNamespace>.<ServiceName>CustomTypes 

For example, suppose a WSDL file describes a service named "MyService". This service provides an operation that references a custom type named "MyCustomType".

When you conform a Web service endpoint to this WSDL file, the newly added operation signature also references this custom type. The name of the type file is "MyServiceMyCustomType.vb" or "MyServiceMyCustomType.cs", depending on whether the associated application is implemented in Visual Basic or Visual C#. In this type file, the namespace and the type definition appear as follows:

[Visual Basic]
Namespace ApplicationName.MyServiceCustomTypes
   Public Class MyCustomType
   ...
   End Class
End Namespace

[Visual C#]
namespace ApplicationName.MyServiceCustomTypes 
{
   public class MyCustomType
   {...}
}

When you conform a Web service endpoint to a WSDL file, different changes occur in these files depending on the following conditions:

  • The service names are the same; however, no existing type definitions have the same name as types described in the WSDL file.

    In this scenario, new type files are added to the solution. These files contain definitions for the new types described in WSDL file. These definitions appear within namespaces with the service name.

  • The service names are the same; however, one or more existing type definitions have the same name as types described in the WSDL file.

    In this scenario, Visual Studio renames the existing type definition by appending the text "_Obsolete" to the type name. Visual Studio adds the new type definition to the same type file and namespace as the formerly conflicting type. Operations for this Web service will then reference the new type instead of the formerly conflicting type.

    Note

    If the namespace already contains a renamed type with the "_Obsolete" string, Visual Studio appends an ordinal to this string to produce a unique name.

    For example, suppose the type file contains a type named "myCustomType". Visual Studio renames it "myCustomType_Obsolete" if the WSDL file also describes a type with the same name. Visual Studio then adds the type definition to the type file.

    If the type file contains "myCustomType_Obsolete" and "myCustomType", Visual Studio renames "myCustomType" to "myCustomType_Obsolete2". Visual Studio adds the type definition to the type file.

  • The service names differ.

    In this scenario, Visual Studio does not modify any of the existing type files. Instead, Visual Studio adds new type files with the new service name to the solution. These files contain definitions for the types described in WSDL file. These definitions appear within namespaces that use the new service name.

    Note

    The Web service class will also update with the new service name.

For more information about custom types, see Web Service Endpoints Based on WSDL Files.

Conforming Only First Matching Operations

A Web service class might implement multiple operations that match an operation described in the WSDL file. In this scenario, only the first matching operation signature will conform to the WSDL file. The remaining matching operation signatures will not change.

To correct this condition, confirm that the correct operation signature was conformed. If appropriate, modify the other matching operations to avoid future duplicates.

Adding Comments About Changes to Code Files

Visual Studio will also add general comments describing these changes to the code files. These comments include the date and the name of the user who made these changes.

See Also

Tasks

How to: Conform Web Service Endpoints to WSDL Files