There is a security "problem"/issue using the XslCompiledTransform.Load() method to load and compile an XSLT stylesheet that contains script (C#, JScript or VB) under IIS/ASP.NET on Windows Server 2003 using Windows authentication and impersonation.
If you have used the XslTransform class in .NET 1.1 to transform XML data using an XSLT stylesheet, then you will know that when you upgrade to .NET 2.0, that this class is now obsolete ("This class has been deprecated. Please use System.Xml.Xsl.XslCompiledTransform instead. http://go.microsoft.com/fwlink/?linkid=14202").
The replacement class (XslCompiledTransform) now compiles the XSLT and then uses the compiled XSLT to perform the XML transform. There is one caveat with this approach. That is, if your XSLT stylesheet contains script of any kind, for instance C#, then the class will generate a temporary compiled assembly DLL in the system's temporary folder - and this is where the trouble with security comes in.
On Windows Server 2003, the .NET 2.0 XslCompiledTransform class attempts to write a temporary 8x3 DLL to C:\WINDOWS\Temp. If you have configured your site, remoting object or other ASP.NET hosted "thing" to use Windows Authentication and to impersonate the current logged on user, then the current logged on user will not typically be a user on the Server and thus does not have rights to write to C:\WINDOWS\Temp.
To get around this problem, I removed the script from my XSLT stylesheet, rather that opening up security for everyone to have write access to C:\WINDOWS\Temp.
IMHO this is an oversight on Microsoft's part. A BCL class should not be attempting to write out arbitrary files/data to the HDD as the BCL cannot assume under what circumstances it will be operating - e.g. across a network share, over click-once, or under ASP.NET. This should definately at least be documented in the MSDN documentation for the class, especially since XslTransform did not do this and has now been obsoleted. This is also not a problem on Windows 2000, although I am not sure why as I havent yet investigated the issue on Windows 2000.
Well I'm back from Tech-Ed 2006. Overall I'd have to say that the technology highlight for me was seeing LINQ in action. The best speaker in my opinion was Kimberly L. Tripp (http://www.sqlskills.com/blogs/kimberly/) who gave a wealth of SQL 2005 presentations/demos on all sorts of fascinating bits and pieces. I must say I picked up the most new tips and tricks from Kimberly's presentations. Kimberly managed to make even the most boring topics interesting to listen to - she clearly has some extreme SQL/SQL Server knowledge and in one demo she even quoted exact KB article numbers off the top of her head.
On the downside, I was hoping for more in-depth sessions on the new technologies WF, WPF and WCF. The sessions were few and far between and only touched the surface; leaving much to be desired.
On the upside, the parties were kick ass, the food was really good and the fireworks/laser show at the closing party was truely spectacular.
And did I mention that it was HOT! 36 degrees Celcius.
I don't know if it is just because I am tired (in the IT sense) or because I am just busy or simply because I have just become lazy, but I like out of the box stuff and I like it to work without having to read a 400 page help file and spend hours on Google searching for the answers. I don't have the energy to stuff around with installers of all things.
Let the stuffing around begin...
Anyway, so we have a complex solution which uses .vdproj Visual Studio 2005 Setup and Deployment projects to build installers. Why I hear you ask? Well because they are there, they are integrated into the solution build and the IDE, they have a simple GUI interface, they don't require you to download and install and configure additional components, they are fully supported by Microsoft (being part of the official VS 2005 RTM and all) and they just work! Yippee, well not quite.
While .vdproj setup projects seemed like a good idea at the time, it turns out it wasnt. So here comes along Microsoft with their NAnt rip-off - MSBuild. But don't even get me started on NAnt - yet another failed open source initiative to add to the ever growing list of open source investments (gambles?) gone south (lets not mention NDoc with VS 2005, .NET 2.0 and generics). Having been burnt by investing hours of development in promising open source technologies such as NDoc and NAnt (that have had no significant work done on them in years and hardly work at all with the new Microsoft technologies), I have decided to stick with Microsoft. But it seems not even Microsoft as it turns out is a good gamble (investment?).
Take the VS 2005 solution files for instance. The project files in VS 2005 are native XML MSBuild files. Of course making the solution file a native XML MSBuild file as well would have been far too logical and way too much to ask, so in their infinite wisdom Microsoft decided to implement yet another useless format (YAUF?), which by the way is not even XML, to define solution files. Heaven only knows why the project files are XML MSBuild project files, while the solution file is some text flat file of a proprietary, unknown, undocumented format? And a flat files of all things? Ever heard of XML? Anyway that aside, at least MSBuild has functionality built in to parse this proprietary solution file and do something useful with it. Of course M$ could have saved some of the $'s if it had simply made the solution file an XML MSBuild project in the first place or at least just XML.
So here's the thing, I have a lovely self-contained solution file that opens up in the VS 2005 IDE and builds like a dream. My developers only have to install trusty VS 2005 and everything just works - no additional downloads, no additional configuration - makes for minimal maintenance and reduces configuration hell. But alas, along comes Team Foundation Server and MSBuild. Err, we don't support .vdproj projects??? What gives? Are you completely stupid or just lacking in brain cells Microsoft? Of course like everything there is a nifty little KB workaorund for the problem. Just install the whole of VS 2005 on the build server, modify all your setup projects in notepad to change all the paths to relative paths (and hope like hell you didn't corrupt the project in the process) and then use the trusty EXEC task in MSBuild to call the VS 2005 IDE to build each setup project individually. Of course if you add new setup projects to your solution you need to add these extra EXEC tasks to the MSBuild project and of course if you ever edit the setup .vdproj, remember to open it up again in trusty notepad and change all the paths. Great Microsoft! Well Done! We love productivity tools like this one.
Ok, so if I have to use MSBuild to build everything else, except the setup projects, and then use devenv.exe (VS 2005 IDE command line) to build the setup apps each individually, why the hell don't I just build the entire solution using devenv.exe and forget about MSBuild? So I'm thinking well maybe there are other cools tasks that MSBuild has (out of the box) that I can use to do more than what my trusty .cmd file that calls devenv.exe can do? Hmmm, I start by looking for the FxCop task? Oh they don't have one... great! However, I can call csc, al and all the rest of the compiler tools sepeartely?! DOH! Yes, I want to do this why? This is why I have a solution and projects to track the dependencies, the references and files to compile in the right order and why I use MSBuild on the solution file and not the individual .cs files. Ok, so there must be more (out of the box of course)... and true enough yes there is... I can copy files, make directories, delete files and do all sorts of nifty command line type things using XML?! HUH? But my .cmd file does this already, funny enough with less lines of "code" and far less angle brackets. Ever heard of the copy command, the md command and the del command?
Anyway that aside, I decide this mismatch of technology bloopers called VS 2005, MSBuild, Team Foundation Server and .vdproj Setup and Deployment projects is not working out. So time to look for an alternative. Of course I really don't want to buy yet another installer such as InstallShield or Wise and then go through yet another learning curve and use yet another proprietary tool (with its own quirks and upgrade path issues and licence issues) and yet another proprietary scripting language...
Hello WiX. Windows Installer XML. A project "open sourced" by Microsoft and used internally by Microsoft. Of course WiX being pure XML has amazing promise, but it lacks out the box'ness. You need to edit XML, which as much as I love XML starts to make my eyes go funny and hurt my hands typing all the angle brackets. There is still no useful GUI for WiX. In fact in the true spirit of open source, the project for the WiX GUI has had no movement for ages. So What to do... Problem 1, is I have to record somewhere that developers must download and install this thing otherwise setup projects are simply not going to compile... I guess I can sort of live with this additional configuration nightmare. However, how on earth do I get these things to build in and out of the VS 2005 IDE? Hello Votive. Votive creates projects for VS 2005 that incorporate the WiX XML into the build of the solution. There are also MSBuild tasks for WiX out the box. This all sounds great from a infrastructure/build point of view, except that I have to install something extra and remember to transfer this knowledge onto future developers. So far so good.
So I fire up Visual Studio 2005; create a new WiX project and hit build. Bloop 2 errors; must specifiy PUT-GUID-HERE. Ok Tools, Create GUID, Copy, paste, Build. Same errors? Oh it doesn't automatically save on build like C# projects do, ok, no problem, click save and then build again. Oops another error:
Error 6 ICE18: KeyPath for Component: 'ProductComponent' is Directory: 'INSTALLLOCATION'. The Directory/Component pair must be listed in the CreateFolders table. C:\Development\Test\WixProject3\WixProject3\Product.wxs 12
Lovely, I have no idea what that means. I can't even get the empty WiX project to build! GRRR... Does this mean I have to read the 400 page documentation? ARG! I guess so. And anyway, since I am editing XML and have no idea what all these elements and attributes do, I guess I have no choice but to go and learn it... but honestly who has 2 or 3 days to master an installer when there is other work to be done... GRRR