Overloading WebMethods

In the object-oriented world of .NET, it is quite possible to use method overloading in the code you develop. A true object-oriented language has support for polymorphism, of which method overloading is a part. Method overloading enables you to have multiple methods that use the same name but have different signatures. With method overloading, one method can be called, but the call is routed to the appropriate method based on the full signature of the request. An example of standard method overloading is illustrated in the following code listing:

  Public Function HelloWorld() As String    Return "Hello" End Function Public Function HelloWorld(ByVal FirstName As String) As String    Return "Hello " & FirstName End Function 

In this example, both methods have the same name, HelloWorld. Which one is called when you invoke HelloWorld depends on the signature you pass to the method. For instance, you might provide the following:

  Label1.Text = HelloWorld() 

This yields a result of just Hello. However, you might invoke the HelloWorld() method using the following signature:

  Label1.Text = HelloWorld("Bill Evjen") 

This returns a result of Hello Bill Evjen. As you can see, method overloading is a great feature that can be effectively utilized by your ASP.NET applications - but how do you go about overloading WebMethods?

If you have already tried to overload any of your WebMethods, you probably got the following error when you pulled up the Web Service in the browser:

 Both System.String HelloWorld(System.String) and System.String HelloWorld() use the message name 'HelloWorld'. Use the MessageName property of the WebMethod custom attribute to specify unique message names for the methods.

As this error states, the extra step you have to take to overload WebMethods is to use the MessageName property. The following bit of code shows how:

  <WebMethod(MessageName:="HelloWorld")> _ Public Function HelloWorld() As String    Return "Hello" End Function <WebMethod(MessageName:="HelloWorldWithFirstName")> _ Public Function HelloWorld(ByVal FirstName As String) As String    Return "Hello " & FirstName End Function 

In addition to adding the MessageName property of the WebMethod attribute, you have to disable your Web Service’s adherence to the WS-I Basic Profile 1.0 specification - which it wouldn’t be doing if you perform WebMethod overloading with your Web Services. You can disable conformance to the WS-I Basic Profile specification in a couple of ways. The first way is to add the <WebServiceBinding> attribute to your code, as illustrated here:

  <WebServiceBinding(ConformsTo := WsiProfiles.None)> _ Public Class MyOverloadingExample    ' Code here End Class 

The other option is to turn off the WS-I Basic Profile 1.0 capability in the web.config file, as shown in the following bit of code:

  <configuration>   <system.web>     <webServices>       <conformanceWarnings>         <remove name="BasicProfile1_1" />       </conformanceWarnings>     </webServices>   </system.web> </configuration> 

After you have enabled your Web Service to overload WebMethods, you can see both WebMethods defined by their MessageName value properties when you pull up the Web Service’s interface test page in the browser (see Figure 26-16).

Figure 26-16

Although the names of the WebMethods are distinct (based on the MessageName property values you assigned in your code through the Web Service’s test page), when the developer consuming the Web Service makes a Web reference to your Web Service, he or she sees only a single method name available (in this example, HelloWorld). This is shown in the IntelliSense of Visual Studio 2005 in the application consuming these methods (see Figure 26-17).

Figure 26-17

In the yellow box that pops up to guide developers on the signature structure, two options are available - one is an empty signature, and the other requires a single string.