Tools for working with XML in Visual Studio 2008

XML is used everywhere from web services, databases, configuration files, to office documents. This article will introduce you to the instrumental support offered by Visual Studio 2008, which facilitates working with XML. This article covers editing XML files, working with XML schemas, debugging XSLT style sheets, and extending Visual Studio by writing your own XML designers.


When you open an XML file in Visual Studio 2008 (for example, .xml, .xsd, .xslt, .svg, or .config), you launch the embedded XML editor. The XML editor comes with the full range of features you would expect from a Visual Studio editor, including IntelliSense, code coloring, parenthesis highlighting, folding / expanding, and code formatting. It provides complete XML 1.0 syntax checking, tag completion, as well as XML schema support with real-time validation.

Editing XML files
')
Admittedly, manual editing of XML files can be very tedious and time consuming. To help this, XML editor Visual Studio 2008 comes with many features to improve performance. One of these functions is an extensible library of XML code fragments — XML files that contain configurable pieces of code that act as templates for use during document editing. Visual Studio installs many XML snippets files that help developers write XML schemas and XSLT style pages. To trigger a snippet while editing the XML file, select “Insert Snippet” from the “Edit> IntelliSense” menu. Once you have inserted a fragment, you can move between highlighted fields, which you can modify with the TAB key to enter data. Figure 1 shows an example of fragment insertion.



Figure 1 : Calling an XML snippet in Visual Studio 2008.

You can also record your own fragments. If you want to create a simple snippet, follow these steps:

Create an XML file and type in it:
<snippet
Click ESCAPE to close the IntelliSense window.
Click TAB .
Enter value.
Press ENTER to complete.

For more details, I recommend publishing to the Visual Studio editor blog.
Code Snippet - Schema Description .

What will you do when there are no ready-made pieces of XML code, and you need to create an XML file based on an existing schema? The XML editor offers a wide range of possibilities with which you can associate your XML documents with XML schemas. Schema-based IntelliSense, real-time validation, and error reporting are just a few of them. In addition to this, the XML editor can dynamically generate code fragments based on an existing schema. After you have provided the name of the element to be added, the XML editor can analyze the schema for the required information, generate a code snippet and insert it for you. To call the functions of dynamic building of XML code fragments, all you need to do is type the name of the element in the same way as in the following example:

<element_name


and press the TAB key. The XML editor will create a code snippet that will look very similar to what was already shown in Figure 1 , except that you will not need to do anything in advance. This is a very powerful feature, especially when you need to create documents with large content models.

By default, the XML editor generates only the required content, but this behavior can be overridden using annotations in XML schemas. You will find more information in MSDN under the heading “How to: Generate an XML Snippet From an XML Schema”.

Schema Cache and Schema Catalogs

For advanced users, the XML editor offers such functions as schema cache directories for schema files. The scheme cache is a folder that contains many well-known W3C schemes, as well as many schemes specifically created by Microsoft or related to their technologies. It serves as a repository of widely used schemes, which usually do not change. You will find the default schema locations in% vsinstalldir% \ xml \ schemas, where "% vsinstalldir%" is a variable representing the location where Visual Studio is installed. When you declare one of the namespaces defined by these schemes in your XML files, the editor will automatically associate the relevant schemes from the cache location and quickly provide IntelliSense and validation for this scheme.

The schema catalog is XML files located in the schema cache directory (catalog.xml file by default). They give advanced users more precise control over the various namespaces that they will probably use. For example, you can associate certain namespaces with external sources:

<Schema
href="mylocation/myschema.xsd"
targetNamespace="http://myschema"/>


You can also use directory files to create associations between schema files and file extensions. This can sometimes be useful when the schema does not have a targetNamespace:

<Association
extension="config"
schema="xml/schemas/dotNetConfig.xsd"/>


Innovation in Visual Studio 2008, you can also add conditions:

<Association
extension="config"
schema="xml/schemas/dotNetConfig30.xsd"
condition="%TargetFrameworkVersion% = 3.0" />


This condition means that the dotNetConfig30.xsd scheme should be associated only when the current project uses the .NET Framework version 3.0.

Finally, you can create a chain from one directory file to another:

<Catalog href="http://mycompany/catalog.xml"/>


Work with large files

Another important editing function that I would like to point out is support for the XML editor for large files. Although you could work with large files in previous versions, Visual Studio 2008 supports incremental analysis of XML documents. Now, if you are working with a 10 MB file, you do not need to wait until Visual Studio analyzes the entire file every time you make changes. The XML editor isolates edits and reanalyzes only those parts that are required, thus offering better performance and response.

I have described just a few of the interesting features of the XML editor, but obviously you cannot see all of them here. Table 1 shows some of the features that are available to Visual Studio users.

Function	Support in Visual Studio 2008
Auto-complete	X
Syntax highlighting	X
Minimize / Maximize code	X
Intellisense	X
Extensible code snippet library	X
Dynamic code snippets	X
Transition to Definition (from XML to XSD)	X
Navigation backward / forward	X
Project and user profile support	X
Real-time Validation	X
Full XSD support	X
Namespace support	X
DTD support	X
XSD generation over XML	X
DTD to XSD conversion	X
Unicode support	X
Large file support (10 MB +)	X

Debugging XSLT Style Sheets

XSLT is the standard transformation language approved by the W3C, which is very popular with a large group of developers. Visual Studio Professional provides editing and debugging support for XSLT style sheets. Editing XSLT files is similar to editing XML files. When it comes to debugging XSLT, Visual Studio supports two main scenarios:

Debugging a separate transformation, which is useful when your initial interest is an input document, the actual transformation and an output document.
CLR-integrated debugging, which is useful for debugging transformations in the context of your CLR application.

Debugging individual transformations

Figure 2 shows the debugging environment when you are working with XSLT transformations. In the default configuration, you can see the XSLT file and tabs for document input types and document output. You can also configure Visual Studio to display all three documents at the same time. When you go through the transformation code, you can see the input data, the transformation that processes this input and the generation of the output file.



Figure 2 : Debugging individual XSLT transformations.

If you are using the C # or Visual Basic debugging environment, you will notice that debugging XSLT looks very much like debugging other programs using the CLR language. All controls and key combinations remain the same. In Figure 2, you can also see the Locals window, which can display hidden XSLT variables (self, position, and last), just like the variables that are defined in your template. You can also see the call stack window, which you can use to navigate to different XSLT templates at the top and bottom of the stack. You can also use the XSLT debugger to set breakpoints in both XSLT code and XML documents.

CLR integrated debugging

Although debugging individual transformations is useful, sometimes you need to debug XSLT as part of your C # or Visual Basic application. The XSLT debugger, which is tightly integrated with other CLR debuggers, allows you to seamlessly transition from C # to XSLT and then to Visual Basic while debugging an application. The following example shows a C # code snippet that uses the XslCompiledTransform class to initialize the XSLT transformation:

XslCompiledTransform xsltcmd =
new XslCompiledTransform( true );
xsltcmd.Load(XSLTFile);
XmlUrlResolver resolver = new XmlUrlResolver();
XmlWriter writer = XmlWriter.Create(OutputFile);

xsltcmd.Transform(XMLFile, writer);

* This source code was highlighted with Source Code Highlighter .

If you set a breakpoint on the method call and pass it, the debugger will show you the XSLT style sheet ( Figure 3 ). All the features described in the debug section of a separate style sheet are also applicable here. The only exception is the ability to set breakpoints in data files. This feature is not available when you switch from XSLT from another CLR program. Everything else will behave exactly as described in the above.



Figure 3 : Debugging XSLT transformations from a C # application.

Table 2 presents a summary of the various functions available during debugging of XSLT transformations.

Feature	Visual Studio 2008 Support
Browser view	X
Locals, watch, call stack	X
Viewing input XML, output, and XLST during debugging	X
Breakpoints in XML	X
Breakpoints in XSLT	X
CLR language debugger integration	X

XML tool extension

The XML editor provides a good basis for developers to create custom designers on top of it. Figure 4 as it was done in the previous version of Visual Studio (Visual Studio 2005). Developers could build an extension on top of the XML Editor via shared buffer access. They should create custom designers by sharing the IVsTextLines buffer and parse the XML using System.Xml.XmlReader or XmlDocument. Don Demsak uses this method when creating XPathmania and XPath add-ons to Visual Studio (for more information about XPathmania, see http://www.donxml.com ). However, since integration occurs at the buffer level, this method creates many large buffer revisions. In addition to this, it has some limitations because the System.Xml parser accepts only valid XML while designers, by definition, must work with non-valid files.



Figure 4 : The old way to create custom XML designers on top of an XML editor.

On the other hand, the XML editor has its own error recovery analyzer. It also creates its own analysis tree representing the contents of the buffer. In Visual Studio 2008, Microsoft opened this LINQ to XML tree to third-party developers. The new architecture is shown in Figure 5. The new API allows developers to create custom views on top of the XML editor's analysis tree, providing them with XML error recovery after the XML editor and a LINQ to XML analysis tree with update transactions, whose execution results appear in an integrated Visual Studio UndoManager buffer. These changes make it easy for developers to create XML tools on top of Visual Studio 2008.



Figure 5 : The way to extend the XML editor in Visual Studio 2008.