How do Datasets manage to get deserialized as DataSets instead of a wsdl.exe-created proxy class?

[Francisco Garcia]

Hi!

I have developed both a Web Service and a client application, and they work
fine.

All classes used in the Web Service interface are declared in an assembly
named Entities, that is referenced both in the Web Service and the client
application.

The problem is that the automatically-generated Web Service proxy class
creates new classes instead of referencing the original classes.

This way, if I add a method to any of the classes in the Entities assembly,
that functionality isn't available in the client application, because the
proxy-generated classes are static snapshots of the server objects, with all
functionality lost.

There must be a way to do this, because that's what DataSets do. If you
create a Web Service that returns a DataSet, and you reference that web
service from a .NET application that knows about System.Data namespace, the
DataSet gets deserialized as a DataSet.

I suppose it must have something to do with Xml attributes or interfaces,
but I can't find which.

Any help is appreciated. Thanks in advance,

Francisco Garcia

[Axel Dahmen]

Hi Francisco,

actually the type System.Data.DataSet is *not* serialized at all... You see,
you already have kind of a snapshot copy both in the references of your
client project and your WebService project. These definitions don't change,
and if they would one would also need to update the corresponding DLLs
accordingly.

Same for WebServices. .NET creates an object of a type by using an Assembly.
The name of the type is given in the SOAP message. Just the name, nothing
more. If you want a Serializable type to be available at "the other end",
you must create a local Assembly defining that type. Otherwise it can't be
constructed on the other machine.

HTH,
Axel
------------------
"Francisco Garcia" <fr*********@no.spam> wrote in message
news:Os**************@TK2MSFTNGP04.phx.gbl...

Hi!

I have developed both a Web Service and a client application, and they work fine.

All classes used in the Web Service interface are declared in an assembly
named Entities, that is referenced both in the Web Service and the client
application.

The problem is that the automatically-generated Web Service proxy class
creates new classes instead of referencing the original classes.

This way, if I add a method to any of the classes in the Entities assembly, that functionality isn't available in the client application, because the
proxy-generated classes are static snapshots of the server objects, with all functionality lost.

There must be a way to do this, because that's what DataSets do. If you
create a Web Service that returns a DataSet, and you reference that web
service from a .NET application that knows about System.Data namespace, the DataSet gets deserialized as a DataSet.

I suppose it must have something to do with Xml attributes or interfaces,
but I can't find which.

Any help is appreciated. Thanks in advance,

Francisco Garcia

[Fran Garcia]

Axel,

I found this in-depth series of articles on returning custom classes from a
web service at
http://www.dalepreston.com/Blog/2005...-from-web.html

Dale Preston answered to a repost of this same question in other newsgroup,
and I copy the answer here so it can help other people.

Thanks

"Axel Dahmen" <Ke********@newsgroups.nospam> escribió en el mensaje
news:eN**************@TK2MSFTNGP04.phx.gbl...

Hi Francisco,

actually the type System.Data.DataSet is *not* serialized at all... You
see,
you already have kind of a snapshot copy both in the references of your
client project and your WebService project. These definitions don't
change,
and if they would one would also need to update the corresponding DLLs
accordingly.

Same for WebServices. .NET creates an object of a type by using an
Assembly.
The name of the type is given in the SOAP message. Just the name, nothing
more. If you want a Serializable type to be available at "the other end",
you must create a local Assembly defining that type. Otherwise it can't be
constructed on the other machine.

HTH,
Axel
------------------
"Francisco Garcia" <fr*********@no.spam> wrote in message
news:Os**************@TK2MSFTNGP04.phx.gbl...

Hi!

I have developed both a Web Service and a client application, and they

work

fine.

All classes used in the Web Service interface are declared in an assembly
named Entities, that is referenced both in the Web Service and the client
application.

The problem is that the automatically-generated Web Service proxy class
creates new classes instead of referencing the original classes.

This way, if I add a method to any of the classes in the Entities

assembly,

that functionality isn't available in the client application, because the
proxy-generated classes are static snapshots of the server objects, with

all

functionality lost.

There must be a way to do this, because that's what DataSets do. If you
create a Web Service that returns a DataSet, and you reference that web
service from a .NET application that knows about System.Data namespace,

the

DataSet gets deserialized as a DataSet.

I suppose it must have something to do with Xml attributes or interfaces,
but I can't find which.

Any help is appreciated. Thanks in advance,

Francisco Garcia

[joez]

.......

"Francisco Garcia" <fr*********@no.spam> wrote in message
news:Os**************@TK2MSFTNGP04.phx.gbl...

Hi!

I have developed both a Web Service and a client application, and they work fine.

All classes used in the Web Service interface are declared in an assembly
named Entities, that is referenced both in the Web Service and the client
application.

The problem is that the automatically-generated Web Service proxy class
creates new classes instead of referencing the original classes.

This way, if I add a method to any of the classes in the Entities assembly, that functionality isn't available in the client application, because the
proxy-generated classes are static snapshots of the server objects, with all functionality lost.

There must be a way to do this, because that's what DataSets do. If you
create a Web Service that returns a DataSet, and you reference that web
service from a .NET application that knows about System.Data namespace, the DataSet gets deserialized as a DataSet.

I suppose it must have something to do with Xml attributes or interfaces,
but I can't find which.

Any help is appreciated. Thanks in advance,

Francisco Garcia