Freigeben über

XSLT debugging in Visual Studio

  • Artikel

Visual Studio is a big tool.  It's easy to miss some useful features.  Hopefully the XSLT debugger won't get missed.   If you want to learn how to use XSLT debugging take a look at Neetu Rajpal's msdn article Introducing Xml tools in VS 2005.  Below you can see the debugger in action as an xslt transform is being applied to some XML.

 

(Please excuse the nonsense XSLT I use in the example.  I haven't had a chance to play around with XSLT for quite some time.)

XSLTdebugging 

XSLT debugging is interesting to me because much of it is the managed debugger.  XSLT is compiled to msil, and the managed debugger is used to provide things like breakpoints and stepping. You can see this by opening the modules window.  You'll see in the last column that the process is a managed process called the Microsoft.XSLDebugProxy.exe, and there will be some modules loaded with names like System.Xml.Xsl.CompiledQuery.1.   All of the debugger windows work as expected: callstack, locals, immediate, threads, modules.  You can see below the callstack for my nonsense example:

 

XSLTcallstackwithJMC 

However! Go to the callstack window and right click to get the context menu. There will be an item called Show External Code. Pick that and you get to see much in the callstack window that was hidden before. The grey colored frames are because there is no debug info (pdb file) for that assembly, which is why those frames were marked as 'External Code' before. The CompiledQuery frames were hidden because the XSLT compiler placed an attribute on them to tell the debugger they were not of interest. With the expanded view you can now see the compiled query and the code that dispatched it.

XSLTCallstackWithoutJMC

However, while that is interesting it is unlikely to help you get at a bug in your XSLT. The Locals window however appears to be one of the more useful windows, that can help you see what is happening as the transforms are applied.

LocalsWindowXSLTdebugging

Comments