My team has been working on some new functionality that’s really configuration heavy. One of the challenges we’ve been facing with this project is managing all of the changes to the central configuration file. In an attempt to add some order to the chaos we decided to start with a base file and apply a series of XSLT sheets to it so we can ensure a consistent state. I haven’t worked with XSLT in years so aside from relearning the language, one of the first things I did was start looking for a tool that could help me build and test my new sheet.
I’ve been using Visual Studio to author XML documents and schemas for years. I’ve taken advantage of IntelliSense and have found the automatic document formatting handy more than a few times. What I didn’t know was that it also has built-in support for not only authoring XSLT sheets but also applying and debugging them.
When working with common XML formats (e.g.: .xml, .xslt, .config, etc…) Visual Studio displays an XML menu and possibly an XML toolbar depending on your preferences. In all honesty, I’ve never really noticed them until now. There aren’t many options available but don’t let that fool you – what’s there can be incredibly useful. The two options that we’re interested in here are:
- Start XSLT Debugging
- Start XSLT Without Debugging
These options allow us to apply an XSLT sheet to an XML document and can be activated from either document type. When either is selected for the first time for a given document and you haven’t already selected a source or style sheet (depending on your document type) Visual Studio will prompt for a file of the opposing type so it can perform the transformation. That is, if an XML document is selected we’ll be prompted for an XSLT sheet and vice versa. Visual Studio will remember which file was selected so we don’t need to select it each time we want to transform a document.
Should you desire to change the selected file you can do so by opening the properties window for the document and clearing the Input property for XSLT files or the style sheet property for XML files. From there you can either select the new document or let Visual Studio prompt you the next time you perform a transformation.
When transforming a document the XSLT engine emits a new document. By default Visual Studio will use a temporary file but we can control where this document is created by setting the Output property in the properties window. Most of the time I used the temporary file but when I was comfortable with the result I changed the output property to overwrite my configuration file (yes, I had a backup).
The Start XSLT Without Debugging (Ctrl + Alt + F5) option is an easy way to quickly transform a document. I used it frequently as I word through relearning the language and wanted to see the result. The real power though is in the debugger.
With the debugger (Alt + F5) we can use breakpoints and step through transformations as though we were working with any other Visual Studio language. The locals window is even populated with self::node(), position(), last(), and any in-scope variables. I found using watches to evaluate XPath expressions invaluable for helping plan out the overall transformation.
Just as with standard debugging any errors that occur during the transformation are written to the output window. The task list also displays any errors and double-clicking on a task will direct you to the corresponding error. XML parser itself caught most of my errors before transformation even started so I really didn’t get to dig into this functionality very much .
Learning about this functionality really helped me get my head back around XSLT. The fact that it’s all contained within Visual Studio meant that I didn’t have to learn new tools as well and was able to write my first XSLT sheet in probably eight years with minimal pain. Thanks, Microsoft!