And by "major" upgrade, you mean moving from 1.3 to 2.0, for example,
which is what we're doing. You are correct in that e.msm is a
Feature/MergeRef replacement for c.msm.
How does that figure into what we're doing?
Thanks!
________________________________
From: Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 11:56 PM
To: Rory Clark; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Reinstalling with different MSM's...
That still sounds as if you're adding and removing components from
features. You'll need to do a major upgrade for that.
If you really want to add e.msm's contents in a minor upgrade (which I
wouldn't really recommend) you need to add a new child feature of an
existing feature and attach the merge module to that feature. The
Platform SDK topic "Changing the Product Code" details how you need to
set up that new feature. I think in WiX you need to set the feature's
attributes to Absent='disallow' InstallDefault='followParent' and if you
don't want it to appear in the feature tree, Display='hidden'.
You're stuck with c.msm's contents until your next major upgrade.
--
Mike Dimmick
________________________________
From: Rory Clark [mailto:[EMAIL PROTECTED]
Sent: 17 May 2007 01:04
To: Mike Dimmick; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Reinstalling with different MSM's...
Thanks for the reply, though I suppose I should've been a been clearer.
Each merge module contains files and is its own component, like this:
* a.msm
directory 1
file-a1.txt
file-a2.txt
* b.msm
directory 2
file-b1.txt
file-b2.txt
* c.msm
directory 3
file-c1.txt
file-c2.txt
* d.msm
directory 4
file-d1.txt
file-d2.txt
Now, the new build of some.msi looks like this:
* a.msm
directory 1
file-a1.txt
file-a2.txt
* b.msm
directory 2
file-b1.txt
file-b2.txt
* d.msm
directory 4
file-d1.txt
file-d2.txt
* e.msm
directory 5
file-e1.txt
file-e2.txt
When we do the "reinstall", none of e's files are written to the drive.
We have files for a through d still, (directory1\file-a1.txt;
directory4\file-d2.txt; etc.), but none from e.msm.
Does that make more sense?
Thanks!
Rory
________________________________
From: Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 2:01 PM
To: Rory Clark; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Reinstalling with different MSM's...
I'm assuming that you're installing the MSMs as files i.e. they're for
your end-users to use to build their own installers, therefore the fact
that they are MSMs is not relevant.
The component rules say you're not allowed to change the makeup of a
component. If all these MSMs are in one component you should break it
into multiple components, and change the product code to do a major
upgrade. If it is one component Windows Installer is likely detecting
that the key file has not changed and therefore it doesn't need to
reinstall the component.
You can add components to new features for a minor upgrade, but I don't
think you're permitted to add components to an existing feature. In
practice this means you cannot remove c.msm even if it were a separate
component. See "Changing the Product Code" in the Platform SDK.
--
Mike Dimmick
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rory Clark
Sent: 16 May 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reinstalling with different MSM's...
We've hit an interesting scenario in our work where we're not seeing one
of the MSM's getting applied in a re-install scenario.
We start off with some.msi that contains the following merge modules:
* a.msm
* b.msm
* c.msm
* d.msm
Some.msi now lays down all of the merge modules to disk as we would
expect them and everything is happy.
Now, we've updated some.msi (with the same ID and upgrade code), but
we've change out a couple of the merge modules, like so:
* a.msm
* b.msm
* d.msm
* e.msm
We have removed c.msm and added e.msm and execute it on the command line
like this:
msiexec /i some.msi /passive /l some.msi.log addlocal=all
reinstall=all reinstallmode=vamus
What we see is that c.msm is still on the disk (as it should be as other
packages are still referring to it), but e.msm has not been written out
to disk.
The question is this: How would we go about insuring that e.msm is
delivered like we think it should be.
Thanks!
Rory
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
