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

[Dale]

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

HTH
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Francisco Garcia" wrote:

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]

Thanks a lot, Dale.

That solved my problem!

"Dale" <da******@nospam.nospam> escribió en el mensaje
news:71**********************************@microsof t.com...

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

HTH
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Francisco Garcia" wrote:

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