Hello,
I have a VC++ managed app that was built and tested against VC80.CRT version 8.0.50727.762. I verified that the embedded manifest points to 762, and the build machine has 762 as the latest VC80.CRT version.
The app has now been also run on a machine that has both 762 as well as a later version of the runtimes (4053).
Both machines, incidentally, are XP Pro SP2; the second machine (the 4053 so to speak) has .NET 3.0.
The app works on the 4053 machine, and I think I understand that due to the Publisher Policy that accompanies the VC80.CRT under the SxS, the app loads 4053 for the application rather than 762 .
For various reasons that I don't want to get into, I've been trying to force it to use the 762 version, so far without success.
At any rate, after researching the literature, I think I understand the chain that determines the target version to load: app config -> publisher policy -> machine config.
So I've come down to placing the myapp.exe.config file (see below) near myapp.exe; note the setting of publisherPolicy to "no" to avoid the second step of the chaining.
The app still loads 4053, rather than 762. Perhaps it's due to what the machine config file says, but I can't even begin to figure out what that file's contents are supposed to mean -- certainly there isn't any reference to VC80.CRT or any of the msvc[x]80.dll libs there.
I expected that referring to an older version of an assembly would be relatively easy to do, being key to overcome 'dll hell' -- even if the assembly publisher feels like guaranteeing backward compatibility (via the publisher policy).
Can anyone shed light?
Thanks
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
<publisherPolicy apply="no" />
<bindingRedirect oldVersion="*" newVersion="8.0.50727.762"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>