Share via

Do you compile XML to IL?

  • Article

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?

 

Example

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)
        {
            Console.WriteLine("Hi!");
#line 4 "xmlfile1.xml"
            Console.WriteLine("ABC!");
            Console.WriteLine("DEF!");
            Console.WriteLine("GHI!");
#line default
            Console.WriteLine("Hi!");
        }
    }
}

File "xmlFile1.xml":

 <?xml version="1.0" encoding="utf-8" ?>
<doc>
  <test>
    abc <-- line 4
    def<br>    ghi
  </test>
  <test>
    other
  </test>
</doc>

 

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

  • Anonymous
    February 27, 2008
    The comment has been removed

  • Anonymous
    February 27, 2008
    Right, just files that have XML contents (not necessarily the xml extension)

  • Anonymous
    February 27, 2008
    "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.

  • Anonymous
    February 27, 2008
    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?

  • Anonymous
    February 27, 2008
    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...

  • Anonymous
    February 28, 2008
    Doesn't XslCompiledTransform compile XML to IL ? Is it affected by this issue ? Cheers, --Jonathan

  • Anonymous
    February 28, 2008
    The comment has been removed

  • Anonymous
    February 28, 2008
    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.

  • Anonymous
    February 28, 2008
    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.

  • Anonymous
    February 28, 2008
    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.

  • Anonymous
    February 28, 2008
    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.

  • Anonymous
    February 29, 2008
    The comment has been removed

  • Anonymous
    March 10, 2008
    The comment has been removed

  • Anonymous
    March 10, 2008
    After submitting my comment I've seen that it is a bit offtopic. Sorry for that.

  • Anonymous
    March 11, 2008
    GProssliner - Not as off topic as may guess ... I've worked on a similar solution (based on the technique here http://blogs.msdn.com/jmstall/archive/2005/07/27/state-machine-theory.aspx ), 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 :)

  • Anonymous
    March 12, 2008
    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 Thanks!