EXSLT.NET and ASP.NET security woes

A guy said he's getting SecurityException whenever he tries to use EXSLT.NET in ASP.NET, while it works in command line with nxslt.exe. We use reflection in EXSLT.NET code (e.g. to return a nodeset from the extension functions using this recipe) and as Dare noted in his "EXSLT: Enhancing the Power of XSLT" article, that imposes Full Trust security requirements. That's why at first I decided that's EXSLT.NET fault and I should find out how to get rid of reflection in the code. That was too quick rush, happily then I realized many people including me do use EXSLT.NET in ASP.NET and it does work fine.

Subsequent investigation shed some light. Using reflection and even heavy sin of instantiating an internal class in XSLT extension object in fact doesn't require Full Trust, but only ReflectionPermission with appropiate flags. Moreover, that just doesn't matter, because using any extension object in XSLT requires real Full Trust due to improved Code Access Security in .NET 1.1. So no matter what we do in EXSLT.NET code, your code (including your XSLT stylesheet) must be fully trusted to be able to use any XSLT extensions. That undoubtedly makes sense otherwise another cool XSLT stylesheet could inspect your hard disk while styling an RSS feed.

The bottom line - to avoid SecurityException when using EXSLT.NET functions in ASP.NET load your XSLT stylesheet from fully trusted place, such as local file system (read more about Code Access Security). If you want to load a stylesheet from a remote web site, you need to make that site fully trusted using either caspol.exe utility or .NET Framework Configuration tool (Mscorcfg.msc).