I am referring to .NET 1.1 and I'm not confusing remoting and Web Services.

The proxy created by VS.NET is a proxy class to the web service class and
exposes the web service class's web methods. The return types of those
methods do not get proxies created for them.

I think you are confusing the web service class itself and the class(es)
that may be returned from them.

"John Saunders" <john.saunders at trizetto.com> wrote

"Scott M." <s-mar (AT) nospam (DOT) nospam> wrote

You are making too many assumptions.

Even in .NET 1.1, other classes were created in the proxy file. This
includes the types used in return values and the types used in parameters.
What's changed in 2.0 is that there appears to be some infrastructure that
now permits the typed datasets to be created in the proxy.

I'm enclosing a small VS.NET 2005 solution which demonstrates the new
behavior. It has two projects: a Web Service project and a Windows Form
client. The service has two methods, each of which returns a different typed
dataset. The Windows Forms project has a web reference to the Web Service.

If you look in the "WindowsApplication1\Web References\localhost" directory,
you'll see that the XML Schema files for both typed datasets have been
imported into the web reference. Further, the References.cs file includes
proxy classes for both typed datasets. Note the comment:

// This type definition was generated by
System.Data.Design.TypedDataSetSchemaImporterExten sion schema importer
extension.

This is the magic that allows VS.NET to generate proxy classes for the typed
datasets. And, if you look at the WSDL file, you'll see why: none of the
structure of the typed datasets is present in the WSDL. A client other than
..NET would not be able to treat these return values as objects of a strong
type. At best, such a client would be able to treat them as XML elements
with a schema to validate against. At that, such a client would need to be
able to interpret the schemaLocation attribute in the <s:import> element in
the WSDL as an actual URL from which to retrieve the schemas, or else the
schemas would need to be provided out-of-band.

One more note, since I've mentioned strongly-typed datasets and schemas in
the same post. ;-)

I've found that the new DataSet designer in VS.NET 2005 does not preserve
the structure of a schema. I had several VS2003 strongly-typed dataset
schemas which, when "converted" to the VS2005 format lost their structure.
Worse, the schema resulting from asking a typed dataset instance to do a
WriteXmlSchema does not match the original schema. The DataSet itself is
added as an outer XmlElement, for instance.

It doesn't matter if you're just using strongly-typed datasets to represent
database tables, but I thought I'd mention it for the benefit of any readers
using XML schemas as XML schemas.

John

John,

Thanks that worked. It seems you need to have the webmethod as strongly
typed dataset for all typed datasets in order for the proxy classes to be
created on the client side. I had only one return type method that's why only
1 proxy class for the strongly typed dataset was being created.

Thanks for your help again!



"John Saunders" wrote:

John,

I don't know what assumptions you think I'm making. In fact, I think you
have made an assumption that I use VS.NET 2005, which I do not, so I can't
open your solution and look at it.

But this is besides the point....

You have described how VS.NET uses XSD's, but your missing the point that an
XSD is not a class and so, can't have a proxy created for it.

The typed-dataset is the class and the XSD is simply an XML representation
of the data structure. Just as a typed-dataset is a .NET class
representation of the structure.

Because a dataset can be serialized as XML, the XML that it produces is
valid with the XSD, but the XSD is in no way used as a class, that's what the
typed-dataset is for.

You yourself prove this when you write:

"Further, the References.cs file includes proxy classes for both typed
datasets"

The proxy is created from the typed dataset (a .NET class), not the XSD (an
XML file).

I may be mistaken about proxies for return types being automatically created
by VS.NET in the web service consumer, but I stand by my assertion that a
typed dataset is NOT an XSD and vice versa. A proxy can be made for a class,
but an XSD isn't a class and so, any proxies are for (just as you wrote) the
dataset class, not the XSD.

I think your confusion here is how tightly VS.NET *can* integrate the
dataset with the xsd. But the XSD, is at it's core an entirely separate
animal from a dataset.

You could say that a typed-dataset is just MS's proprietary .NET way of
working with the W3C standard XML validation document.

"John Saunders" wrote:

"N. Shehzad" <NShehzad (AT) discussions (DOT) microsoft.com> wrote

Yes, I've found that, in general, only the classes which are referenced in
the web method signatures are generated as proxy classes on the client side.
That is, the classes need to be used for return values or as parameters.

One other thing I've noticed: if you have a method that takes a parameter of
type Base, then type Derived does not have a proxy class generated for it.
Only if Derived is explicitly used in a method signature is the proxy
generated for it.

John