WCF Service parameters changed in .NET 2.0 client

Question

I created a WCF service that exposed a method that has one paramater:

public class Service1 : IService1
{
    public string GetData(int value)
    {
        return string.Format("You entered: {0}", value);
    }
}

The service has two endpoints defined (wsHttpBinding and basicHttpBinding) so that it would be compatable with older clients.

The service runs just fine in a .NET 3.0 and .NET 3.5 client app. However, when I create a .NET 2.0 client, the GetData method requires 2 parameters: an integer (expected) and a bool parameter called valueSpecified (unexpected). I never defined the second parameter. Why is this happening and how can I get rid of the second parameter?

Answer 1

Since value types can't be null (in latter versions of .net framework there is no Nullable<T>) VS besides to generate additional parameter to give you ability to not specify value type, you can call your service method like this.

service.GetData(val,true);

see this post, where John Saunders suggest to add [DataMember(Required = true)] attribute in the property.

Answer 2

You could manually remove the valueSpecified property from GetData operation within your proxy class.

Answer 3

The exact same question has been posted here.

Another way to avoid the extra boolean parameter to be generated on the client proxy when using .NET 2.0 is to switch to RPC-style enconding in the service contract (the default for both WCF and ASMX is Document Style).
This way the XmlSerializer on the client will make sure that the parameter always appears in the SOAP requests since it's part of the SOAP 1.1 specification, which is enforced when using the RPC-Style encoding.

In WCF you can specify the encoding style using the DataContractFormat attribute, either at the service or at the operation level.

[ServiceContract]
public interface IService
{
    [OperationContract]
    [DataContractFormat(Style = OperationFormatStyle.Rpc)]
    string GetData(int value);
}

More information on the differences between RPC Style and Document Style encoding in SOAP can be found here.

In any case please consider carefully the implications of changing the contract of your services, since it can potentially break compatibility with any existing clients.