We’re nearly code complete on the next version of Visual Studio, and will soon be releasing a Community Technology Preview (CTP) so that you can take a look, work on prototypes, and think about how the new features might fit into your development plans. This is the first Orcas CTP that has feature parity with the May 2006 CTP, which was built with prototype code rather than production code. We have spent the last 9 months in a very extensive process of reviewing designs and code, thoroughly testing implementations and fixing bugs that were discovered, performing usability studies, and so forth. Likewise, this is the first Orcas CTP that can be installed side by side Visual Studio 2005 – no more annoying warning messages about an unsupported compiler, no need to uninstall the CTP in order to do real work on a machine.
The planned final release date for Visual Studio “Orcas” is not yet public, but you can expect an initial Beta 1 when it is Spring here, and a feature complete Beta 2 in the Summer.
There are three major areas in which you will see improved XML functionality in Orcas:
- XSLT compiler and debugger
- XML editor
- LINQ to XML
XSLTC.exe – Save compiled XSLT stylesheets as a DLL
The compiled stylesheets feature that was introduced in .NET 2.0 has been useful and popular, and this takes it a step further. Rather than compiling the stylesheet on each deployment environment and taking a potential performance hit each time, we are providing an xsltc.exe a command line tool that can be used to compile multiple stylesheets into one assembly. Deployed applications can load the compiled stylesheets from the assembly using XslCompiledTransform. This will also make deployment of XSLT solutions less cumbersome, especially when multiple stylesheets imported and included. Today, someone needs to keep track of all the stylesheets and manually move them to the deployment machine; with Orcas, you can just deploy the .NET assembly that these compile into.
XSLT Debugger Data Breakpoints –
This feature enables users to put a breakpoint on nodes in the source document. The XSLT Debugger will stop on this breakpoint when this node becomes the Current Node during transformation.
Why is this important? In Visual Studio 2005, tracing execution step by step is impossible with a large source document. The simplest and most typical debugger scenario is setting a breakpoint somewhere in the stylesheet and hitting F5. Most often, however, you want to see how a particular code fragment works with specific data, but the code fragment with the breakpoint may be executed hundreds times before it will be called in the context of the node of interest. Hence Data Breakpoints can be very useful when debugging stylesheets that are run against large XML documents.
XSLT Debugger Context Visualization –
There have been improvements to make it easier to determine what the current node is and to display the information in the current context at each step in a debugging session.
XML Editor Improvements
There are two areas where you will see improved XML editor functionality in Orcas. First, it handles very large XML documents better than in Visual Studio 2005. There is still an overhead to load a document that depends on its size, but now you can search, display, and edit sections of a large document more effectively. For example, the Intellisense hints display quickly.
Second, the XML editor now exposes its internal data via a LINQ-based API. This is primarily intended for those developing VS plugins; you don’t have to work with raw XML text or low level APIs, you can use a more usable API that exposes both well-formed XML trees and ill-formed text (along with the parsing errors). This API is used in some internal projects, but will be available to all in the Orcas release.
LINQ to XML
We’ve talked a lot about LINQ to XML (formerly known as “XLinq”) over the last 18 months, so you probably know the basic story. For this CTP, we have made the following substantial changes since May 2006:
- Bridge Classes
These implementations of System.Xml interfaces such as XmlReader, XmlWriter, and XPathNavigator will allow XPath / XSLT to be used over LINQ to XML trees, allow XSLT transformations to produce an LINQ to XML tree, and allow efficient data interchange between DOM and LINQ to XML applications. There is also a Validate extension method to validate an XElement tree against an XML Schema.
- Event Model
This allows LINQ to XML trees to be efficiently synchronized with a GUI, e.g. a Windows Presentation Foundation application
- XObject class
There is a new base class for both XElement and XAttribute, introduced largely to support the event model.
- XStreamingElement class (temporarily) removed
This was done because there was uncertainty about the design of various features to support efficient production and consumption of large XML documents. The result of the design exercise – completed after the February CTP code lockdown — was to confirm the original design of XStreamingElement, so it will be put back in the next release. OK, it sounds dumb in retrospect, but there were a lot of ideas on the table that would have required breaking changes, so we did what seemed prudent.
- Various understandability / usability improvements – There have been a number of relatively minor changes done in response to internal reviews, usability studies, and external feedback to make the API more clean and consistent.
Still to come in LINQ to XML before Orcas ships:
- The IXmlSerializable interface will be supported.
- The XStreamingElement class will be added back to allow trees of enumerators to be defined that can be “lazily” serialized as XML in a deferred manner. Streaming input can be supported using the existing XmlReader API and the public LINQ to XML API; we’ll be discussing how to do that and publishing some fairly simple sample code that handles some generic scenarios quite efficiently even with huge documents. We have decided not to try to bake a general-purpose streaming input API into LINQ to XML itself in Orcas, however.
- The IXmlSerializeable interface will be implemented to facilitate the use of LINQ to XML in conjunction with the Microsoft web services APIs.
February should be a much busier month on the XML Team weblog. The XML team will have a number of posts in the days leading up to the February CTP release that go into more detail on these features and timeframes. We’ll also be talking about other features that we are working on that will not ship in Orcas but will be shown in their own CTPs in the coming months. Once the February CTP is out, we’ll post and point you to updated documentation that didn’t make it onto the setup program, and we’ll be posting sample code and hands-on advice how to use these new capabilities to their full potential.
As always, let us know what you are thinking about all this, what you would like to see improved, and how we can better meet your XML data programmability needs.