apocryph.org Notes to my future self

I've said it before, and I'll say it again: Side-by-side assemblies are WAY worse than DLL Hell

I’ve bitched at length about Microsoft’s side-by-side scheme for ending the “DLL hell” that used to rule Windows, whereby multiple applications would each write their preferred DLL to Windows\System32, and break other apps that expected a different version. Microsoft set out to fix this problem with what I can only assume was a room full of PhD’s and no input from working programmers or sysadmins, since the resulting abomination takes a hard, non-obvious problem and replaces it with a very hard, virtually inscrutable problem.

Twice so far in the last 24 hours has this has bit me in the ass. First, I was trying to run some code on a test VM which I built on my development machine. Since I wanted to, you know, debug this code, I created a ‘debug’ build, which links the executable with the debug version of the Microsoft C runtimes. Every developer who’s ever tried to do this knows it won’t Just Work, since the debug runtimes won’t be present on the box. What I used to do was manually copy all the DebugCRT and DebugMFC files from my dev machine’s c:\windows\winsxs directory into the destination machines, which is exactly what Microsoft admonishes us not to do, but they don’t leave me much choice.

However, this VM I’m using this time is Windows Server 2008, whereon even the mighty Administrator doesn’t have write privs to winsxs; that’s limited to the Trusted Installer user. Sure, I could munge the privs, but this is supposed to be a test box, so I don’t want to munge it too far afield of what our customers’ configs will look like. So, I do what the WinSxs (say “win sucks”, because it does) guys suggest is to find the Debug_NoRedist folder in the Visual Studio 2008 install directory, copy the folders there under your architecture directly into the directory where your application is located, and voila!, through the magic of WinSxs, it will Just Work.

And, it would have. Except the Visual Studio team apparently doesn’t really get WinSxs either, because after I installed Visual Studio 2008 SP1, it updated the Debug_NoRedist folder with the new SP1 runtimes, which includes manifests that reflect the SP1 version of the debug CRT (9.0.30729.1), and not the old RTM version (9.0.21022.8). That’s the right call, except the binaries produced by SP1 have in their embedded assembly manifest a reference to the CRT version 9.0.21022.8. This works fine on a dev workstation where both the RTM and SP1 versions of the runtimes are installed, since there’s a policy file in the WinSxs directory that redirects requests for 9.0.21022.8 to the 9.0.30729.1 version. However, when you’re doing an isolated application that loads the CRTs from the current directory, there is no such redirect, so the app looks for 9.0.21022.8 and can only find 9.0.30729.1, so it eats shit and dies.

The fix? You’ll love it. Edit the Microsoft.VC90.DebugCRT.manifest file to change the version number from 9.0.30729.1 to 9.0.21022.8, and QED. Yes, that makes me feel dirty, but at least it works, which is more than I can say for the so-called “correct” way.

To whichever team came up with WinSxs: FUCK YOU ASSHOLES!

The second and more subtle way in which this bit me in the ass had to do with using CreateProcess to spawn an executable with a path like this: c:\foo\bar..\boo\baz.exe; that is, a .. somewhere in the path. That works fine normally, but if we’re using the debug runtimes, and there’s a Microsoft.VC90.DebugCRT directory in c:\foo\bar and also one in c:\foo\boo, then I get crashes the first time I allocate memory from a DLL and free it from the process. I can verify only one instance of the CRT DLLs are loaded into the process, and I can verify the DLL is compiled correctly, because when I switch from c:\foo\bar..\boo\baz.exe to c:\foo\boo\baz.exe with no other changes, it works fine.

Is this WinSxs’ fault or the CRT’s fault? Does it really matter? No: FUCK YOU ASSHOLES!