Peter Rosin skrev:
I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll, MSVC8 generated a manifest, but I
instead embedded the manifest pointing to an older msvcr80.
I.e. Embedded this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
instead of what MSVC8 generated, which was this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
Then I created an exe using both fopen (some other libc function) and
consuming this dll, and in that exe I embedded the generated manifest
(i.e. version 8.0.50727.762). Looking at this exe with depends.exe
reveals that only one msvcr80.dll is loaded. That might be a bug in
depends.exe though.
Turns out there's a "policy" involved as well. For all assemblies
on my system containing msvcr80.dll (there's currently three) the
policy says to redirect older versions to the one the policy is
for. I.e. for version 8.0.50727.1433 of the assembly, there's
this in the policy file:
<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.1433"/>
<bindingRedirect oldVersion="8.0.50727.42-8.0.50727.1433"
newVersion="8.0.50727.1433"/>
That explains why I only saw one of the dlls being loaded.
However, why are versions 8.0.50608.1-8.0.50727.41 not being
redirected? That's disheartening...
So I took the liberty of temporarily renaming the policy files,
and I could indeed make depends.exe show something other than the
.1433 dll, but I could not make it show two different libc at the
same time. With the policy files renamed, I also failed to make
depends.exe show two different msvcr80.dll when using LoadLibrary
on the dll instead of linking with the import library, so that's
something...
Cheers,
Peter