Well, for the apps I'm building installers for, we've already decided
against static linking, so we need to deploy the DLLs somehow. In the
past, we've just included the merge modules using installshield, which I
believe deploys the DLLs to the system32 directory, but I've also tested
with including a private copy of the DLLs, and this also appears to
work. I'm not sure if this is a permitted option though.
When installing a merge module, is there a way to specify the module's
install directory? For example, if I want to install the CRT MSM from
VS 2005, I can put something like this in:
<Merge Id="crt.B22E6F9A-D396-4F96-84D9-A822C63B9994" Language="1033"
DiskId="1" SourceFile="C:\Program Files\Common Files\Merge
Modules\Microsoft_VC80_CRT_x86.msm"/>
Since this is under a "directory" tag though, I don't know where it'll
install the files. The module default should be the system32 directory,
shouldn't it?
________________________________
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, March 19, 2007 8:44 AM
To: Mike Dimmick; Chris Bardon; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Consensus about CRT/MCF merge modules?
Agreed. However, based on early reports I'm not sure that pushing
patches into WinSxS is really working due to the complexity that is the
CustomActions to work around bugs in WinXP. The ideas behind Fusion are
interesting but the complexity of the system has made it difficult to
verify and for users to truly understand it.
Personally, I prefer a model where a patch to a shared binary has the
ability to update that binary everywhere (not that I can get anyone in
Microsoft to agree with me, so maybe I'm just confused <smile/>).
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Friday, March 16, 2007 12:56 PM
To: Rob Mensching; 'Chris Bardon'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules?
However, with static linking you have the servicing problem - if there's
a security issue in the CRT (not unknown) or in MFC, you will have to
rebuild your application to pick up the fix, then rerelease your
application. By contrast, if using the WinSxS versions, Microsoft can
ship an update directly to end-users (either as an updated assembly with
the same version number, but different file version number, or as an
additional assembly with a newer version number plus a policy binding).
I have to admit looking at how the VS2005 CRT merge modules work and
being a bit confused as to why they're configured to do something
different on Vista (not just using MsiAssembly/MsiAssemblyName tables)
especially as they were released over a year before Vista was.
Using a private copy of the DLLs in your application directory is also a
possibility but I don't think this is recommended (or even permitted?)
for a final distribution. It still has the servicing problem but not the
problem of having to rebuild the application or having the large
binaries.
--
Mike Dimmick
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 16 March 2007 16:35
To: Chris Bardon; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules?
I'm not quite yet ready to make this a "recommendation" but I'm
currently leaning towards statically linking the libraries directly.
I'm seeing hints that the WinSxS/Fusion stuff they did for these
libraries in VS2005 has some seriously bad repercussions when it comes
to patching and some possibly strange behavior on Vista. It's a
research project I'm doing slowly...
For the WiX toolset, we statically link to the CRT (MFC, haven't done
that since I wrote Orca <grin/>) to minimize our dependencies on the
machine. That makes the binaries a bit bigger but it is worth it to not
have to worry about "Is the WinSxS store updated at X point in time in
my install?"
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Bardon
Sent: Friday, March 16, 2007 9:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Consensus about CRT/MCF merge modules?
Looking through the archives, there appear to be a couple of ways to
include things like the CRT and MFC redistributables in an installer.
Some have advocated including the DLLs directly, which seems to go
against the concept of having a redistributable MSM to link against. I
tried building with the Microsoft CRT msm that comes with VS 2005, and
got a long list of warnings from light.
Is there a "recommended" method for dealing with these kinds of
dependencies?
Chris
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
