I have a project that comprises pre-build Dll modules, built some time in the past, using Visual Studio 9.
The EXE of the project is built now, using SP1 of Visual Studio 9.
When we deploy the EXE we don't want to require administrative access, so the C-Runtime has been bundled into the root of the application. The Dlls: MSVCRT90.DLL and their Manifest: Microsoft.VC90.CRT.manifest
Now, the EXE and latest versions of the runtime manifests are all in agreement - the application manifest asks for 9.0.30729.1 of msvcrt.dll, and the crt-manifest contains the entries confirming that msvcrt90.dll is version 9.0.30729.1
Now, a problem. A 3rd party DLL library used by our application was linked against the original msvcrt90.dll version 9.0.21022.8 and has an internal manifest to this effect.
On our development PCs where both versions of the VS9 CRuntime have been installed the app works. On "fresh" PCs where we install the app for the first time - the DLL fails to load.
Now, I have some cheats I can do - one is to revert the app to 9.0.2 - get the 9.0.2 DLLs off the original source media. This is undesirable as 9.0.3 is preferable. Or I try really hard to get a rebuild of the 3rd party library.
I am furthermore pretty certain that, on our development PCs, when the 3rd party library asks for the old dll it gets redirected to the new dll - they are binary compatible.
Application manifests and assemblies were meant to save us all from this kind of rubbish. It must be possible to edit the assembly manifest files so that both the exe and dll can load.