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:
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:
static void Main(string args)
#line 4 "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.