problem with classes: client v. web service

[cstacy]

My application sometimes wants to process objects it gets from a web service, but sometimes wants to process purely local objects. In either case, the objects implement the same protocol. For example, both locally created and ws created objects have a "title" property that I want to read.

I would like to have a shared definition of this common protocol, and I would like to call the same method names on both kinds of objects. Let's say the objects are called "chunks". If I try to make a Chunk class, abstract class, or interface, or derivations from those, and share a definition (Add Reference) and code to it in both the web service and the local code, I get problems. No matter how I approach it, I seem to end up with "can't implement the interface" type errors on one end or the other.

What's the right way to define this common behavior on each side of my system?

[tlhintoq]

Try this tutorial for making custom classes, then inheriting from those.

[cstacy]

Thanks, but your tutorial doesn't seem to have anything to do with what I asked.

[cstacy]

Let me ask this a different way.

What is the best practice for using the same object definitions on the client and service side? My objects happen to be trivial to serialize, but are composite objects (eg. Foo.title, Foo.text, Foo.issueNumber ; members are just strings and ints and such).

The way I am doing it now is that I have a third project that has class definitions in it; both client and server side have references to it. I use WSDL.EXE to generate a proxy class. Then I hand-modify the proxy class to eliminate its class definition of the proxy Foo, and add a "Using" statement to reference the third project instead. When I add the proxy file to the client project, the proxy generates the correct (original) data class common to client and server.

I guess what I want is some advice about the elegance of modifying auto-generated WSDL files, or a way to tell WSDL that it can use certain class definitions (rather than making up proxy classes), or perhaps I am going about this all wrong.