Ok, after further investigation the origin of the .Net 2.0 dependency on binaries created with VC8 Express is becoming clearer. The major change that has occurred in VC8 is that the core C/C++ runtime libraries and standard libraries like STL, MFC, ATL etc are now configured as ‘side-by-side native assemblies’ rather than the usual simple native DLLs. The point of this is to allow version control over shared libraries so that different applications don’t mess each other up by overwriting shared DLLs. This is all well and good, although I don’t think it’s really needed for the core C+ runtime libraries, which have been around forever and already have their version encoded in the name, e.g. msvcr70.dll and msvcr71.dll (and now msvcr80.dll). I guess I can see why they’d want to homogenise all this, but it does make it more awkward for the native app developer.
What happens is that a manifest is embedded in your resulting binary which lists which versions of DLLs are required (this can be separated as another file too, but the default is embedded). In operating systems that support side-by-side assemblies (like WinXP), this manifest will be parsed and the libraries loaded from the appropriate subfolder of %WINDIR%\WinSxS (e.g. ‘x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.00.0.0_x-ww_09876c28’ - nice eh? :)). This means that the right version of these runtime libraries has to be installed using Windows Installer (ie MSI database), you can’t just use nice simple installer tools like NSIS or Inno to plonk these DLLs in your app’s directory (or even the Windows system folder). It’s worth noting that this is still supposed to work on older operating systems too (like Win98) that don’t have a WinSxS area - the installer will just revert to the plain old system32 way and manifest information in the binaries will be ignored. You might think you could therefore cheat and just slap the DLLs in there anyway on all operating systems - I haven’t tried this yet but I suspect it won’t work since XP will parse the manifest and insist that it has to use the assembly route and can’t use the old unregistered DLL load route.
So, I think this is the underlying deployment problem - of course if you already have the .Net 2.0 platform installed you have these libs already configured so you’re ok, but in theory I think you can get this to work without, provided you build your installer as an MSI. It is quite restricting, and I don’t like it very much, but there we are. It’s also worth noting that if you don’t want to require the user to have administrator provileges, you can install the ‘assemblies’ (DLLs) as private versions in the app’s folder, but they still have to be set up with an MSI I think.
I don’t think VC8 Express comes with MSI building features (I’ll have to check when I get home), which is perhaps why this has turned into a larger problem. I’ll have to look around for a decent free MSI builder, since my favorite tools listed above can’t produce MSI as far as I’m aware.
I can’t say I like this. It reminds me far too much of COM object registration and all the messy nightmares that implies. Personally I like being able to just slap a bunch of files in a folder, with no external or global configuration. The private assemblies approach might be the closest we can get to this. This section of MSDN is a good place to start learning about this.