Re: ATL/CRT deployed as private assemblies
- From: "Ted" <ted@xxxxxxxx>
- Date: Wed, 9 Jul 2008 10:20:00 -0400
The ATL redist folder that comes with VC2005 SP1 has a bug in it. The
version in the manifest file is wrong, it doesn't even match the DLL that's
there. You can fix the manifest by hand in notepad.
Yes, you're correct, if you have private assemblies installed, and also
WinSxS files, it will always use the WinSxS files if they are available, and
use policy redirects that are installed to WinSxS as well. So you cannot
force your app to use your own private assemblies unless you config files or
use an undocumented trick of removing the publickeytoken (discovered by
Jochen).
Here's the link:
http://blog.kalmbachnet.de/?postid=80
Ted.
"linearred" <nospam@xxxxxxxxxxxxx> wrote in message
news:%23faSasS4IHA.4492@xxxxxxxxxxxxxxxxxxxxxxx
Hey folks,
We'd like to deploy a COM server dll with the ATL and CRT libraries as
private assemblies. The COM server itself can't be "regfree" (as far as I
can tell) because it's a Shell Extension. We're trying to create this as
a .msm to be included in a larger .msi.
I created a merge module setup and deployment project in Visual Studio
2005 and manually dragged the ATL and CRT redistributable folders into the
application folder with the COM dll (as directed in the Visual Studio
tutorial on creating an isolated application) and built the .msm. The
.msm was then merged into a simple wrapper deployment project to test it
as a .msi . When the server is deployed via the .msi, it seems to work
OK, and the redistributables folders I included are in the same folder as
the dll. However, when I run "depends" on the dll, it appears to be
loading a later set of ATL/CRT runtimes from the winsxs folder. (The dll
in this case has an embedded manifest.)
I see that there are policy folders for these sxs runtimes that redirect
to the later versions, but what I took away from the first MSDN / VStudio
articles I read comparing side-by-side and isolated applications was that
if private assemblies were deployed with the dll, then the private
assemblies would be used regardless of what was in sxs, i.e., you could
specify that the system load the actual runtimes you had tested the dll
with. What I have since read
(http://msdn.microsoft.com/en-us/library/aa374224(VS.85).aspx) in trying
to understand what I'm actually seeing in the dependency walker is that
the private assemblies are only used if there isn't an equivalent *or*
supserseding (by virtue of a policy file) version already in sxs. The
only other way I can see to force the use of the private assemblies is if
I hand-modify the embedded COM server dll manifest to specify <file>
elements that explictly point to the private assemblies.
Is this correct, i.e., private assemblies are actually only used as a
"next-to-last resort", or am I missing some setting or other in VStudio to
force the private assembly runtimes to be used?
Thanks.
.
- Follow-Ups:
- Re: ATL/CRT deployed as private assemblies
- From: linearred
- Re: ATL/CRT deployed as private assemblies
- References:
- ATL/CRT deployed as private assemblies
- From: linearred
- ATL/CRT deployed as private assemblies
- Prev by Date: Re: Application Configuration File for using CRT locally in VC++ 9
- Next by Date: Re: ATL/CRT deployed as private assemblies
- Previous by thread: ATL/CRT deployed as private assemblies
- Next by thread: Re: ATL/CRT deployed as private assemblies
- Index(es):
Relevant Pages
|