C#: Webservice changes expected parameter type (from a normal POCO to a an autogenerated class)

Question

I have the following class in Class Library: Artist, which is a POCO

Now I have a method in a web-service (which has a reference to the mentioned-above library) with a signature like this:

[WebMethod]
public int Artist_AddArtist(Artist a) {
 //
}

When I try to consume this service from an application (that also has a reference to the mentioned-above Class library), the expected parameter of the Artist_AddArtist method is not Artist, but a new type of Artist that is being generated in Reference.cs which is a partial class that is auto-generated.

Thus since in my application I use, supposedly the same Artist class from the library and now the Web Service method expects this new auto generated type, I cannot pass an instance of it to the web-service.

How can I fix this issue?

Answer 1

Maybe switching to WCF services is an option for you. As far as I remember, with a WCF service, you can reuse the same types on ther server and client side.

This article explains how to migrate an ASMX web service to a WCF service.

Answer 2

You cannot, and should not, fix the problem.

Some others will tell you to do things like edit the generated file, but that's not a good practice (as the changes will go away as soon as the Web Reference is updated).

What you're seeing is by design. See Basics: How Web Services Work.

Briefly, when you use "Add Web Reference", Visual Studio downloads the WSDL file from the service, and uses the XML Schemas from the WSDL to create some proxy classes to represent the XML described by the schema. It also creates a proxy class for the service itself, having methods for each operation in the service.

The proxy data classes can serialize to the XML that the service is expecting to receive, and can be deserialized back from the XML that the server sends in reply.

One way to think of it is that you only have this problem because both client and service are .NET. If your client were written in Java, then you wouldn't be thinking of sharing classes.

---

Note that WCF can do this, if necessary. It introduces a dependency between the client and service (they both have to use compatible versions of the assembly containing the classes), but when you need to do it, the option is there. It's useful when there is behavior in these classes that must be used both by the client and by the service.