How to copy data from CLR object to its proxy?

[Max Christian]

On the client, I have a type myAssembly.myClass from the same assembly
the server uses, and its proxy, localhost.myClass, generated via the
Web Reference.

I can call Web Methods passing objects of type localhost.myClass
without any trouble. But what I need to be able to do is pass (the
data from) myAssembly.myClass objects on the client.

It isn't possible to cast from myAssembly.myClass to localhost.myClass
using CType. I could write code manually to copy data memberwise from
a myAssembly.myClass object to a localhost.myClass object, but the
class is huge and so it would create terrible maintenance problems.

I can't quite understand why there aren't hundreds of people out there
with this problem -- I must be missing something obvious. Do people
really fill in the fields of object parameters to web services without
ever needing to take the values from a CLR object?

Anyway, is there any sensible way to copy the data from a CLR object
to its Web Service proxy?

Thank you very much for any help,

Max Christian
[replace NEWS with my first name in email address to respond]

[Jan Tielens]

I agree: this is the problem a lot of people who are starting with web
services are facing. You really need to be aware that you are dealing with
proxy classes on your client side.

First of all I have to say: what you are trying to do is not really "service
oriented". Service orientation is all about sharing schema's instead of
sharing types. When you use a web service in your application there is a
clear separation between your business logic and your client, that
separation is the web service. There are many articles written about SOA,
and they probably explain things a lot better than I do, so I suggest you
Google for "Service Oriented Architecture" or take a look at following
articles:

[url]http://msdn.microsoft.com/architecture/journal/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp[/url]
[url]http://msdn.microsoft.com/architecture/journal/default.aspx[/url]

Secondly, if you really want to share types instead of schema's: you can use
your assembly on your client side. You only need to alter the generated code
of the web service reference, so it will use your class instead of the proxy
class.

--
Greetz
Jan
________________
Read my weblog: [url]http://weblogs.asp.net/jan[/url]


"Max Christian" <news@maxuk.net> schreef in bericht
news:c6ad177c.0405312215.168e33c1@posting.google.c om...

> On the client, I have a type myAssembly.myClass from the same assembly
> the server uses, and its proxy, localhost.myClass, generated via the
> Web Reference.
>
> I can call Web Methods passing objects of type localhost.myClass
> without any trouble. But what I need to be able to do is pass (the
> data from) myAssembly.myClass objects on the client.
>
> It isn't possible to cast from myAssembly.myClass to localhost.myClass
> using CType. I could write code manually to copy data memberwise from
> a myAssembly.myClass object to a localhost.myClass object, but the
> class is huge and so it would create terrible maintenance problems.
>
> I can't quite understand why there aren't hundreds of people out there
> with this problem -- I must be missing something obvious. Do people
> really fill in the fields of object parameters to web services without
> ever needing to take the values from a CLR object?
>
> Anyway, is there any sensible way to copy the data from a CLR object
> to its Web Service proxy?
>
> Thank you very much for any help,
>
> Max Christian
> [replace NEWS with my first name in email address to respond]

[Max Christian]

"Jan Tielens" <jan@no.spam.please.leadit.be> wrote...

> First of all I have to say: what you are trying to do is not really "service
> oriented". Service orientation is all about sharing schema's instead of

Thanks Jan, modifying the generated code fixed it and thanks to your
explanation of SOA I can see why a bit of a hack is necessary.

I'm converting a project that appropriately uses .NET Remoting to use
Web Services instead when it isn't really the right technology. Why?
Because Web Services can be accessed from code running in the internet
zone, whereas Remoting cannot. It's a hack but the zero-touch
deployment makes it very rewarding.

Cheers,

Max Christian