I was writing about loading XSLT stylesheets embedded into assemblies (dll or exe) recently and Richard Quinn asked this very legitimate question:
But why oh why would anyone embed their XSLT in the assembly? The point is to separate design from logic. Even if the xslt does a non-presentational transform it _will_ be a pain to have to redeploy the assembly instead of just the stylesheet. Or not?
Well, having XSLT stylesheets externally no doubt has many benefits. But embedding XSLT stylesheets into deploy units (be it dll, exe or jar) is also done not without a reason. After all two the most often used in the wild XSLT stylesheets are embedded. I'm talking about res://msxml.dll/defaultss.xsl (technically not XSLT stylesheet) and chrome://global/content/xml/XMLPrettyPrint.xsl - respectively Internet Explorer and Firefox XML pretty printers.
Embedding stylesheet doesn't necessarily mean coupling presentation and logic layers, in fact it has nothing to do with any application design issues. It's just deployment strategy and in that sense XSLT stylesheets aren't different from images or scripts.
Sure, when your XSLT file is just laying around you can tweak it without reinstalling application (sometimes even without restarting it). Sometimes that's useful and sometimes you don't want users to play with your stylesheet, because allowing that means:
- more code to write - you have to anticipate possible stylesheet changes, corruption or removal
- more testing
- potential security hole, because don't forget XSLT is a programming language and if that's not enough it can include extensions so that enables lots of interesting code injection scenarios for black hats. Sure with .NET 2.0 XSLT security options you can limit what XSLT stylesheet can perform, but then - it's your stylesheet and you are limiting yourself in the first place.
Again, sometimes deployment is easier if you don't have to bother about all that little files to be placed into the right place.
Some people embed, obfuscate and encrypt XSLT stylesheets trying to prevent reverse engineering. Well, apparently they do it for a reason too.
Performance is another interesting point. I think loading string resources should be a little bit faster than loading from the disk. Didn't test it though.
But the whole new era of XSLT embedding is going to start when XSLT finally becomes widely compilable into executable code. Next Visual Studio (codename Orcas, expected later this year) will include XSLTC.EXE - XSLT to MSIL compiler. That would add another benefit - save on XSLT compilation, which is time and resource hog.
If you do embed your XSLT stylesheets, I wonder what are your reasons?
@Mattio,
> It's a new one for me and going straight into my Bloglines account.
Oh, Oleg is one of the XSLT UberGods for the .NET platform, the other being Dimitre Novatchev. You may already be subscribed, but just in case > http://dnovatchev.spaces.live.com/
Between Oleg and Dimitre, I learn more about how to take *FULL* advantage of what the .NET platform has to offer the XML developer than *ANY* other source.
Also, you can get both Oleg, Dimitre, as well as a strong base of XML developers, evangelists, etc... (the list, of course, includes Dr. Kay) via http://planet.xmlhack.com
>> I think I need to generalize EmbeddedResourceResolver and include it into the Mvp.Xml library so we could just use it and not reinventing again and again.
That would ROCK!!!
BTW, I have both the Mvp.Xml as well as nxslt projects running via Mono inside of the nuXleus project. (see: http://nuxleus.com/dev/ for more detail.) I am in process of building out the next release which will be based on top of the VHD format for VPC/VServer. Will let you know when its ready so you can check it out.
I've used the approach of embedding an XSL file to keep a class library wrapped together in an single DLL and to prevent well-intentioned tinkerers from making changes to a simple but critical transformation setp.
Thanks to David for posting this on XSL-List! It's a new one for me and going straight into my Bloglines account.
That's doable with XmlResolver. Take a look at my earlier post - http://www.tkachenko.com/blog/archives/000653.html
>> One reason *not* to do deploy in an assembly is that the VS.NET 2005 XSLT debugger will not only fail to step into the source of a stylesheet which has been loaded from an assembly, it will crash the IDE. (I haven't tried this with SP1 yet, but I assume it's still the case)
WOW! Hadn't realized that one... YIKES!
One other point which is really more of a question: The piece of this that presents an interesting challenge is how to go about the import/include process with embedded transformation files. The way I have handled this in the past has been simply blending the various transformation files into one, but this is less than optimal for obvious reasons.
I have thought about simply writing a URI scheme handler and using res://name_of_resource, but then wondered if this functionality didn't already exist and I simply needed to research it some more. If not obvious, I have yet to do that research ;-)
One reason *not* to do deploy in an assembly is that the VS.NET 2005 XSLT debugger will not only fail to step into the source of a stylesheet which has been loaded from an assembly, it will crash the IDE. (I haven't tried this with SP1 yet, but I assume it's still the case)
>> If you do embed your XSLT stylesheets, I wonder what are your reasons?
* Ease of referencing a resource property value by name instead of having to use the on-disk string location. This becomes a bigger deal when you want to be able to dynamically select a transformation file based on user input.
* Speed: It's most definitely faster to access an embedded resource.
* Deployment: Sending out a single DLL is always best. This becomes quite a bit more obvious (sending out a zip file is often the counter-argument to this) when you provide access to the embedded transformations files by referencing a single DLL in your project.