Sorry, man, you need to go check your facts. Create an example and see what
happens. I did, and it behaves as I posted.

My only question (which I'll check when I get a chance) is what happens when
there's more than one typed dataset involved. One of the posters said that
only one proxy is generated, and since my example only used one typed
dataset, I can't tell if he's correct or not.

John

Are both datasets used as return values?

As an experiment, try changing the return type of the method whose dataset
is being created in the proxy class with one of those that is not:

Now a proxy for class A is being created:

[WebMethod]
A Method1(){return new A();}

[WebMethod]
B Method2(){return new B();}

Change it to this and see what happens:

[WebMethod]
B Method1(){return new B();}

[WebMethod]
A Method2(){return new A();}

John

They are related, but they are not one in the same.  Have you noticed that
you can delete either the typed dataset or the XSD and continue to use
whichever remains?

XSD's are not a MS invention, they are the W3C standard schema mechanism.  A
typed DataSet is a .NET class that is modeled after your data structure, an
XSD is an XML Schema that is modeled after your data.

They can work together, but they are not the same thing.  An XSD is not
defined in the .NET Framework.  A DataSet is. An XSD is not a class (and so
you can't have a proxy class for something that isn't a class in the first
place), a typed DataSet is.

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.TypedDataSetSchemaImporterExtension 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