I'm just in the process of upgrading a ASP.Net 1.1 application up to .Net 3.5 and one of the changes I've made is to use XslCompiledTransform rather than XslTransform. I was running through some test XSLTs to ensure all was well when I found an XSLT that failed using the new method.
After a bit of investigation I found that the XSLT had a huge xsl:choose statement with 435 conditions, sample below:-
<xsl:choose>
<xsl:when test=".='0'">Not Applicable</xsl:when>
<xsl:when test=".='A01'">Hartlepool</xsl:when>
<xsl:when test=".='A02'">North Tees</xsl:when>
.... abbreviated for the sake of sanity......
<xsl:when test=".='ZE0'">Eastern Board</xsl:when>
<xsl:when test=".='ZN0'">Northern Board</xsl:when>
<xsl:when test=".='ZS0'">Southern Board</xsl:when>
<xsl:when test=".='ZW0'">Western Board</xsl:when>
<xsl:otherwise>N/A</xsl:otherwise>
</xsl:choose>
Commenting out the above xsl:choose allows the transformation to work however leaving it in is currently crashing my IIS application pool and the only solution is to restart the app pool.
I realise a 435 condition choose statement isn't a great idea for a variety of reasons (I inherited this code please don't hold it against me) and I am going to look at resolving this particular problem in another way however I'm interested as to why this worked previously using XslTransform but doesn't with the XslCompiledTransform. Is there something in particular I need to look out for or is this freakishly large choose statement just a one off.