Apr
8
The other day a co-worker got into a situation in which he tried to invoke a Web Service but was getting unexpected or no results. He was upgrading/maintaining an application that was written in .Net 1.1. Parts of his maintenance tasks were to invoke a service that was recently deployed in the company.
I took a look at the services WSDL and realized that his problem is probably due to the fact the WebService was using Nullable Types which were introduced in .Net 2.0. At first that may not seem like an issue.
A Nullable Type for say, int, is used to hold all the possible values of int and a null value. In pre 2.0 days, this was not possible resulting in a multitude of work-arounds. But since 2.0 it is possible to give a variable of type Nullable int a value of null to indicate that the variable has not been instantiated or assigned.
So in this particular case, any use of Nullable Types in the Web Service were being treated as optional parameters.
When using Visual Studio 2003 to add a Web Service Reference or manually executing Wsdl.exe that comes with .Net SDK (1.0 and 1.1), the proxy that is generated is does not take into account Nullable Types because the concept did not exist at the time these tools came out. The generated proxy represents an int? as just int. If this proxy was used to call the Service, it would pass a 0 for that field as a default value rather than null which in turn would cause the WebService to think the client intended to pass a 0.
A quick fix to this problem is to manually edit the proxy after it has been generated and change the type of the fields/properties to string. System.String is capable of holding a range of characters and a null value. The drawback will be that the proxy will not be a 100% strongly typed, but this can be fixed with encapsulation of the filed/property.