Howdy,
GS > With the manifest in place, it will *not* try to load the DLLs from the
local directory (this is done to prohibit tampering of shared libraries).
Regis >But [1] says the searching sequence for the private assembly is:
Regis >
Regis > 1. Side-by-side searches the WinSxS folder.
Regis > 2. \\<appdir>\<assemblyname>.DLL
Regis > 3. \\<appdir>\<assemblyname>.manifest
Regis > 4. \\<appdir>\<assemblyname>\<assemblyname>.DLL
Regis > 5. \\<appdir>\<assemblyname>\<assemblyname>.manifest
Regis >
So, just to be clear, the <assemblyname> is not the same as the DLL name.
== This is where WinSxS gets *really* complicated. ==
With WinSxS, an "Assembly" is a collection of *one or more* files specified by
a manifest.
The <assemblyname> is often == to a DLL name, but there is no requirement for
this to be true.
the <assemblyname> in this case is "Microsoft.VC80.CRT".
When WinSxS looks for local (private) assemblies, it's looking for either:
a DLL called "Microsoft.VC80.CRT.DLL" with a manifest resource or
an XML manifest file called "Microsoft.VC80.CRT.manifest"
that tells WinSxS about the files (dlls) in the manifest.
The assembly manifest (not to be confused with the application manifest)
describes the contents of the assembly.
In the case of the VC runtime, the manifest actually contains three DLL files:
msvcr80.dll
msvcp80.dll
msvcm80.dll
Regis >And I also found that manifest for redist CRT [2] has following lines:
Regis >
Regis > <assemblyIdentity
Regis > type="win32"
Regis > name="Microsoft.VC80.CRT"
Regis > version="8.0.50608.0"
Regis > processorArchitecture="amd64"
Regis > publicKeyToken="1fc8b3b9a1e18e3b"
Regis > />
Regis >
Regis >but the version of msvcr80.dll in that folder is 8.0.50727.42
Regis >
Regis >[1] http://msdn.microsoft.com/en-us/library/aa374224%28VS.85%29.aspx
Regis >
Regis >[2] "C:\Program Files (x86)\Microsoft Visual Studio
8\VC\redist\amd64\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest"
Regis >
To be clear, just because you have version 8.0.50727.42 installed, does not
mean that the
binding policy redirecting 8.0.50608.0 to that newer version is installed.
** In My Opinion ** this should be the norm, but the VC++ team thought
otherwise at the time.
To check if you have the Binding Policy installed, there will be a a file
somewhere deep inside the c:\Windows\WinSxS folder with a name like
"amd64_policy.8.0.microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_1492cce54f6d20f0.manifest"
On Win2k3/XP the naming is different than on Vista and beyond, so I can't tell
off the top of my head.
It should have "amd64" , "policy" , "8.0" , "microsoft.vc80.crt" in the
filename.
If you have that file (which I suspect you don't) it would redirect requests
for "8.0.50608.0" to "8.0.50727.42".
To get the Binding Policy, I believe the EXE installer of the 8.0.50727.42
needs to be installed.
GS >
GS > Now, the publisher of the library can issue updates to the library and
GS > redirect binding at runtime. This is done with what's called a "Binding
Policy" in a "Publisher Configuration File". (Essentially, this policy tells
the OS to redirect requests from a version range to a different version). Now,
the tricky part is, depending on how the newer version of the library got
installed, the policy may or may not have been included. When the VC++
libraries are installed as part of a merge module (.msm) in an MSI installer,
they don't redirect old versions of the library to the new one (the idea being
that you don't neccesarily want old apps pointing to the new runtime[1]). I
believe if the VC++ redistributable (by installer [2]) is installed, it does
install the new Binding Policy.
GS >
GS > By removing the Manifest, the OS just looks in the local directory for the
libraries--this is not what you really really want--you'd need to include the
VC++ runtimes in the application directory with the redistribution of Harmony
itself.
GS >
Regis > Does it mean if we include the VC++ runtimes in Harmony local directory
and expected it is used at runtime, we have to removing the manifest?
The *proper* way to include the runtimes in your local directory would be to
place the manifest there (as <appdir>\Microsoft.VC80.CRT.manifest) and the
files alongside it.
The *easy* way is to remove the assembly reference from your exe's manifest.
Garrett
