XML Features in the February CTP of Visual Studio “Orcas”

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

XSLT Improvements

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.


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.

Mike Champion

Comments (12)
  1. Is there going to be an XmlNodeWriter in Orcas? It’s a fairly glaring hole, especially if you’ve ever wanted to apply an XSL transformation to an in-memory XmlDocument and get the result as another in-memory XmlDocument. You can pass the input to the transform via XmlNodeReader, but to get it back out again you just have to feed your XmlWriter to a StringBuilder and then parse it…

    Fortunately my use case wasn’t performance-critical, but it’s still ugly…

  2. Stuart, XmlNodeWriter in .NET 2.0 is hiding in

    xmlNode.createNavigator().AppendChild() method. It can be used to populate XmlNode via XmlWriter API and so you can

    XmlDocument doc = new XmlDocument();

    using (XmlWriter writer = doc.CreateNavigator().AppendChild()) {

       xslt.Transform(input, (XsltArgumentList)null, writer);


    Mike, am I right that  Orcas January CTP includes none of these coolness?

  3. I was writing about loading XSLT stylesheets embedded into assemblies (dll or exe) recently and Richard Quinn asked this very legitimate question: But why oh why would anyone embed their XSLT in the assembly? The point is to separate design from logic.

  4. XmlTeam says:

    Oleg, to be honest I don’t know for sure, but I don’t think so  –  the February CTP is the release where we will present what all is ready to show, what has been documented, what has been tested end-to-end, etc.  

  5. Fred says:

    Any sign of XSLT 2.0 support?

  6. Steve says:

    This post implies that the next CTP is soon and the link below states that the FEB CTP has been delayed to March.

    Will there be a release in Feb?  Will it have WPF support?


  7. XmlTeam says:

    I don’t know anything about the eventual ship date for the "February" CTP.  All the XML code that is going in is loaded on board, but I don’t know when the train will leave the station.  We’ll update if we hear anything.  The whole point of the Feb CTP, however, is not so much to have the train run ontime but to make sure that all the May 2006 prototype cargo has been remanufactured to production spec and carefully reloaded.  

    As for XSLT 2, the short answer is "Not in Orcas, therefore not in the Feb CTP".  See the previous XML Team post.

  8. I’ve been waiting for quite some time for this release. For start, I’ve been playing a lot with Linq

  9. I’ve been waiting for quite some time for this release. For start, I’ve been playing a lot with Linq

  10. The Community Technology Preview of the next version of the .NET components that the XML team ships is

  11. In a previous post we presented an overview of the XML Features in the "Orcas" Community Technology Preview

  12. So here is nXSLTC.exe v1.0b – an experimental XSLT compiler for .NET 3.5 (Visual Studio "Orcas"). Get it here (free open-source). I probably shouldn’t be building this tool, but I have my reasons. Why not? As a matter of fact, Mike Champion has announced

Comments are closed.

Skip to main content