Do you compile XML to IL?

We need some customer feedback to determine if we fix a regression that was added in VS2008.

Any language can target the CLR by compiling the language to IL, and then you immediately leverage the .NET platform, including access to the libraries and debugging tools.

Do you write a compiler that takes an XML source file in and then compiles it to IL, produces a managed PDB, and then expect to be able to debug the XML source file using the source-line information you put in the PDB?  For example, if MSBuild compiled to IL (instead of being interpreted), it would fall under this category.

Compilation techniques could mean:

  1. using Reflection.Emit and MarkSequencePoint
  2. compiling to C# source code with #line directives that refer back to the XML.
  3. emitting IL text files and using ilasm to produce
  4. using the unmanaged emit APIs directly.


What's regressed?

In VS2005, you can set breakpoints on source lines in the XML file (that map to the ranges specified in the PDB you emitted alongside the IL) and hit them. You can also do set-next-statement and do stepping.

In vS2008, setting code breakpoints in the XML file may not be hit. Instead, the IDE will inspect the source file contents to recognize it's XML and so ignore the managed PDB code ranges and attempt to set an xml data-breakpoint on the entire XML element. The data-breakpoint is designed to cooperate with the XML libraries, but not the managed PDBs. Thus the code breakpoint is not hit and you won't stop in the xml file. Does this impact you?



Here's a very simple way to see the impact of this using case #2 above:

using System;
using System.Collections.Generic;
using System.Text;

namespace xml_debug
    class Program
        static void Main(string[] args)
#line 4 "xmlfile1.xml"
#line default

File "xmlFile1.xml":

<?xml version="1.0" encoding="utf-8" ?>
    abc <-- line 4


The #line directive in the C# file would cause the next lines (up to #line default) to be associated with lines in the XML file, thus having the PDB associate the xml file with the IL. You can try this out in both VS2005 and VS2008 as a default C# console application to get a feel for the differences and extent of the issue.

Comments (16)

  1. Benjamin says:

    Did I understand it right? This is only a problem with XML files? Other files will work with #line? If it is so, this is not a problem for me…

  2. Right, just files that have XML contents (not necessarily the xml extension)

  3. Ondrej Svitek says:

    "In VS2008, setting code breakpoints in the XML file may not be hit. Instead, the IDE will inspect the source file contents to recognize it’s XML and so ignore the managed PDB code ranges and attempt to set an xml data-breakpoint on the entire XML element."

    This is obviously a failure, with VS trying to be too smart about user’s intentions. It would be vital to add some option for switching this feature off and restore flawless xml debugging experience thus.

  4. Ondrej – yes, it’s definitely a failure; hence why I’m blogging about it.

    Does it impact you? Do you ever compile XML to IL?

  5. Just to be clear, what is it that triggers this? Is it the XML header in the file? Or is it the XML editor itself? If I opened the XML file in the text editor and set a breakpoint, would it work?

    I am soon to be affected by this. I have a templating system that takes XML as input and spits out domain objects in C# as output (using NVelocity as engine). I would have liked to map the property declarations in the C# back to the XML…

  6. Jonathan Perret says:

    Doesn’t XslCompiledTransform compile XML to IL ? Is it affected by this issue ?



  7. BrianJ says:

    "We need some customer feedback to determine if we fix a regression that was added in VS2008."

    I’m not sure I understand this opening line.  Are you implying there is a chance it won’t be fixed if you don’t get enough feedback here?  Of course you should fix it. 🙂  Not only is it a bug but a regression bug.

    To answer your other question: Do I compile Xml?  No I don’t today but thanks for the warning.  Its definitely something to be aware of should I want to do this in the future as I have an increasing amount of C# and Xml to maintain.

  8. Kent – I’d recommend you take a few minutes to play with the sample above in VS2005 and Vs2008 to get a feel for what the experience is and see if it impacts you.  Let me know!

    Jonathan – Re XSLT – this change cooperates with the .NET fx’s particular implementation of XSLT transforms.

  9. Brian – "Are you implying there is a chance it won’t be fixed if you don’t get enough feedback here?"

    Technically, no; practically, yes.

    My blog post here is just 1 avenue of soliciting feedback.

    This regression is non-trivial to fix (it’s not just adding a null check), so we need to prioritize it.

    I’m implying that bugs that don’t impact people are treated with lower priority and take longer (potentially years) to get fixed.

    If a lot of people are impacted by this, then it’s more important to delay other work to get a fix for this.

    If nobody is actually impacted by this, then other work (such as other cool features) may be more important.

    If not a single person replied here, it would be tempting to conclude nobody cares and there’s no urgency to fix it.

    The flip side is that if a lot of different folks reply with different scenarios practically impacted, there’s more urgency.

  10. OK, tried it. It will affect me unless I work around it.

    Here’s a synopsis:

    – as noted, it is only the XML editor that is affected. Therefore, getting your file to open in the source editor would be a viable workaround

    – .xml files will open with the XML editor. There does not appear to be a way to open these files with the text editor. Open With…Source Editor does not work.

    – XML content in a .txt file will open in the text editor and will work

    – XML content in an unrecognized file extension will still open in the XML editor by default, because VS will see the XML header and  assume the content is XML. However, using the Open With… approach will work.

    That last point is my workaround, because my files are actually stored with a ‘.bo’ extension (business object). However, it’s still kind of annoying and for people with .xml files I don’t see a workaround at all, which is icky.

  11. Ondrej Svitek says:

    Mike, I am not sure if you got my yesterday’s reply, since it hasn’t showed up here.

    Shortly, we have a workflow engine at work, that produces xml description of the flow. This is later compiled to IL (to be precise, translated to C# source which gets compiled afterwards). Currently we have a custom tool for debugging purposes, being able to use VS here seems quite interesting to me. On the other hand, if there are other possibilities (like using Mdbg), I don’t see that much of  a problem for me here.

  12. Ondrej – I only got your 1 reply from stamped at 1:44 AM, which I replied to at 2:35 AM.

    Why do you have a custom debuggin tool? Could C#’s #line pragmas solve your problem?

    You could always customize MDbg, but it’s a toy compared to VS.

  13. GProssliner says:

    When you choose a language to be compiled, emitting symbols is an manageable task.

    But often there are scenarios where you cannot implement a compiler of an language which is interpreted just to get debugging work.

    I’ve developed a prototype for a dynamic debugging engine, which allows interpreted languages to emit symbols at runtime without the needing to emit the code for the execution. Basically you implement an interface which includes FileName and LineNumber properties. When these statements are executed, you call a method on the Debug-Engine which takes an instance of this interface.

    If you are interested in, I can send you the project. I would also be very interested in what you would think about such an solution and maybe you have some comments for improvement.


  14. GProssliner says:

    After submitting my comment I’ve seen that it is a bit offtopic. Sorry for that.

  15. GProssliner – Not as off topic as may guess …

    I’ve worked on a similar solution (based on the technique here ), and first hit this XML problem when applying that solution to an interpreter that took in XML.

    If you’re running into any problems, feel free to post questions about that… it could always make good blog fodder 🙂

  16. GProssliner says:

    According to the code-fragment below, the input of the statemachine within your posting isn’t actually read from the file, or is it?

    new PrintState(10,      2,      2), // 0  <— start state

    new PrintState(30,      0,      3), // 1

    new PrintState(20,      1,      6), // 2

    I would appreciate your feedback on my implementation. Is there any other way to contact you than the comment-section of your blog? My email: guenter(dot)prossliner(at)world(minus)direct(dot)at


Skip to main content