How do I use a common class between winforms client and web service?

Question

I have inherited a large admin winforms application that shares a 'Common' library of classes for holding data with a web service. The problem I am having is that if I return a populated instance of a class from a web service call then it comes out on the client as a different type and I cannot use the other 'Common' project logic to manipulate.

This is because although the web service will return an object of type Common.Widget it will then wrap that object up in order to transfer it over the wire. Once this is done I can't cast the object back to the 'common' type because .Net throws an InvalidCastException.

I've done this with WCF and the DataMember attribute but I can't upgrade this project to WCF right now as it is very large and the test server is Win2K (no .Net 3+ for Win2K).

So is there a way for me to do this easily or do I have to translate all of the data I get from the web service back to the raw types in the common library?

Thanks in advance

Ryan

Answer 1

I hope there's a better way than this, but: if you include the common library only with your web service, and then define a web service that returns an object of the type you want to use in both environments (e.g. your Widget class), you can then use objects of type Widget in your winforms client. I think the cast exception you're seeing is because you're including the Common library in both projects - even though they're named the same, your winforms app treats the Common in it's own project as different from the Common in the web service.

The approach I mentioned above (including Common only in the web service) will let you use Common objects in the winforms app even if they don't come from the web service (i.e. you can create them locally with the "new" keyword).

Answer 2

The issue is that when your objects come over the wire, they are deserialized into classes that are private to the web service's proxy. So even though the names of the classes are the same, it's a separate class. And you'll notice (if you use F12 in Visual Studio) that the classes from the webservice don't have all the methods of the classes in the "common" project.

Answer 3

This is the way it's supposed to be.

If the code is working now, what does it do currently when you return one of these types? It must translate it, which is how ASMX web services were intended to behave.