Debuging XSLT from a string in .NET

It seems that the more cool and powerful a language is, the worst are its debugging facilities. JavaScript was like that some years ago and XSLT is like that right now. That you can debug such an exotic thing as XSLT at all is a surprise, but once you get a taste of the F10 fruit, you can never have enough.

Right now if you go into your C# project and do a transform like:

string xslt, xml, html; //Suppose these have meaningful values

XslCompiledTransform tranform = new XslCompiledTransform(true);

tranform.Load(new XmlTextReader(new StringReader(xslt)));

tranform.Transform(

new XmlTextReader(new StringReader(xml)),

new XmlTextWriter(new StringWriter(html)));

You cannot debug it. The debugger wants a file it can look at, and there isn't any, since you are getting the xslt from a string. It's a clearcut debugger limitation, but how can we workaround it?

Well, after much research I think there is no way, unless ... you can change the code. In that case you can write:

string xslt, xml, html; //Suppose these have meaningful values

XslCompiledTransform tranform = new XslCompiledTransform(true);

string tempFileName = Path.GetTempFileName();

File.WriteAllText(tempFileName, xslt);

tranform.Load(tempFileName);

tranform.Transform(

new XmlTextReader(new StringReader(xml)),

new XmlTextWriter(new StringWriter(html)));

Voila, now VS will happily let you debug the xslt, because it has a file to look at - the temporary one. It sucks to create the file and it is certainly impractical to leave it on on a production system. You can use it while debugging and later on remove it, or you can use the code in a #if debug statement, that will revert back to the correct implementation on release builds.

You you have found a better way to debug xslt from a string, let me know, and until then happy xslt-ing.

A diary of problems and solutions

It just hit me. Often times I spend 2, 4 hours or even a day killing myself with one little issue in my programs. Be it a documentation snafoo on the libraries, a problem with an algorithm, or a misconception about a language feature. What's common among those is that they are very obscure corner cases, ones that don't even get solved by the best web search available. If the answers were spelled out in the web somewhere, I could have spent those investigation hours being productive and writing code.

I can't prove it, but I have a feeling that most people have the same problems and they usually solve them - I usually do - , because everything always works out in the end. But that does not help anyone else, because that solution becomes a lunchtime anecdote at best. So here's my tiny contribution to solve that. Every time that I get stuck with something, I'll post here on how I detangled myself.

With enough luck the search engines will do a good enough job of surfacing those little gold nuggets of information to those in need.

I don't expect this post to be particularly useful to anyone, just to give some context, in the case this collection of random problem and solutions ever get some page view love, so let's keep it short and wait for the first nugget :-)