I am hoping someone from Microsoft can answer this one for me. As a developer I rely on quite a few libraries to get my job done. Quite a few of those .NET base libraries make use of some fundamental framework "givens" such as the XML API, there are others - but I'll use this for my example. Imagine my surprise then when playing around with XML in an application that good old System.Xml.XmlDocument is no longer there and a new type exists, Windows.Data.Xml.Dom.XmlDocument which is similar - but not exactly the same.
For example - want to get all of the XML from the document? There is no InnerXml which you might be familiar with, it appears to have been replaced by a method called "GetXml()". Don't get me wrong, I think what Microsoft is doing from a UI metaphor point of view is awesome, but the level of disrespect that is being shown to .NET developers and the fundamental building blocks of the framework is just staggering. C# and VB.NET aren't just languages that operate in isolation from the underlying framework. It is a carefully crafted synergy.
This is just one simple example, but it is such a fundamental one. As it stands, a developer hoping to pick up a .NET portable library and move it across to metro is going to be in for a nasty surprise. Sadly I realise that you are probably too far into the ship cycle to address these issues, which means the damage is done. Surely there has to be someone in the Windows team advocating for the .NET developers and the 10+ year old APIs that have existed in the platform.
Mitch DennyWednesday, June 06, 2012 2:51 PM
The old XML dom APIs (System.Xml.XmlDocument and friends) have been deprecated in favor of the System.Xml.Linq APIs (XDocument). As a managed developer you are welcome to use WinRT's XML APIs as well, but I would recommend using XDocument instead, as it supports the C#/VB Linq syntax and is portable between the different .NET platforms (desktop, phone and Silverlight).
Does this help?
Immo Landwerth | .NET Framework Team (BCL) | http://blogs.msdn.com/b/bclteam/
Wednesday, June 06, 2012 6:18 PM
- Edited by Immo Landwerth [MSFT]Microsoft employee Wednesday, June 06, 2012 6:20 PM
It helps me understand why it was removed but then it opens up a more disturbing question. XmlDocument is such a fundamental class to existing software libraries that the level of incompatibility that this introduces at the library level is amazing. Further, the BCL mechanism for flagging intention to deprecate an API, the ObsoleteAttribute has not been applied to XmlDocument in the desktop/server framework.
I can see why you might decide not to take a specific API over to Metro's pseudo .NET environment, but System.Xml.XmlDocument is fairly widely adopted. The situation this creates is that class libraries that could otherwise be portable need to be changed to use XElement, or have some kind of compiler switches (and associated complicated build process) to account for both XmlDocument in the system hierarchy, and XmlDocument in the Windows hierarchy.
It also begs the question - if XElement is so awesome (I don't have anything against the XElement model by the way), why does the new WinRT plumbing require XmlDocument? Must be for compatibility ... hmmm.
Mitch DennyWednesday, June 06, 2012 10:34 PM
I also found the transition (and still am) a little jarring. The lack of any support for System.Data was a particular sore spot for me (***luckly***, SQLite has stepped in as an option to help with a local storage database that supports SQL). I still much prefer .Net but there is something to be said that for the most part I can use Java code I wrote in 1997 in applications today.
Obviously these changes are not impossible to deal with but for example it is frustrating to have to re-write basic code like reading text files every time a new platform is released (a traditional winforms app vs. a WP7 app vs. a WinRT app, etc).
Wednesday, September 05, 2012 1:14 AM
- Edited by bpell Wednesday, September 05, 2012 1:17 AM
that's a real pitty! I work a lot with XML Signatures an did not find anything like SignedXML in WinRT XML API. It is possible to reference the System.Security.... to have SignedXML available, ist totally unusable because System.XML referes to Dom.Xml...
Specialised in data encryption, digital signatur, smart card management, electronic invoicing, VSTO & Sharepoint development, Windows 8 Apps, Windows Phone Apps, http://www.bogad.atTuesday, January 08, 2013 4:59 PM