When you call DataSet.GetXml, the DataSet is turned into a string. It's no longer a DataSet. I say DataSet is difficult to be serialized by xml because the DataSet object itself is not marked as DataContract. You can't serialize a DataSet object. When you use DataSet.GetXml to return a string in your web service, the generated SOAP proxy class has no knowledge of the meaning of that string. On desktop .NET and .NET Compact Framework, you can use DataSet.ReadXml to construct a new DataSet object, and use it in Windows Forms and ASP.NET data binding scenarios. Windows Forms's data binding model has sophisticated supporting for binding to DataSet, especially for DataGridView. But Silverlight doesn't. IMO there're several reasons:
First, as you probably know, the desktop System.Data.dll assembly is more than 2 Mb. Even if we can cut off most features, it will still introduce a large increment on the size of runtime. As a browser plug-in, we have to keep the Silverlight runtime as small as possible.
Second, the data binding model in Silverlight is a subset of that in WPF, and is significantly different from Windows Forms and ASP.NET. In WPF, when you try to bind to a DataTable, we'll call its IListSource.GetList method to create an IList object, which is actually a DataView. Each member in the DataView is of type DataViewRow, which implements ICustomTypeDescriptor. ICustomTypeDescriptor is used to dynamically construct a type. But this interface is not in Silverlight yet. Even static reflection has limitations in Silverlight due to security concerns. So this model can't work in Silverlight. Also by dynamically constructing a type, performance will drop. See this blog post for more information.
Third, while I can't 100% assure you at this time, it's likely that we'll support ADO.NET Data Service (Astoria) in Beta2. Astoria is a special kind of WCF REST service. It does a good job for data driven applications. It's built on top of Entity Framework, and it'll expose the data as JSON or ATOM, and it's extensible. See this blog post for more information. Also we already support LINQ to XML, so you can easily create an object model from a generic REST service. With so many support for modern architectures, I don't see any values supporting DataSet will add. But anyway, you can continue ask for this feature. If enough people are asking for that, it's likely to be supported in VNext.
以上是在某论坛看到的原因 无非就是不便序列化,DLL太大不适合web,不符合json OR ATOM