I am not sure what you mean by "have MigrateFeatureStates set in the
Upgrade entry for only that product you want to migrate the features
from".

I have the following for my upgrade xml:

<Upgrade Id="40e665b9-9825-4b2b-b3e1-ebf6082e57a4">
        <UpgradeVersion Property="OLDAPPFOUND" IgnoreRemoveFailure="no"
IncludeMinimum="yes" Minimum="5.0.0.0" IncludeMaximum="no"
Maximum="5.3.0.0" Language="1033" MigrateFeatures="yes" />
        <UpgradeVersion Property="NEWAPPFOUND" IncludeMinimum="no"
OnlyDetect="yes" Minimum="5.3.0.0" Language="1033" />
</Upgrade>

To be clear about how I am making all this work, I have embedded
transforms of the product code to support multiple side by side
installations of our application.  I also have a bootstrapper
application which presents a list of installed instances for the user,
and then builds the appropriate command line string to pass to msiexec
based on the instance selected.  If the instance is older than the
current version, it permits an upgrade, and passes in the product code
for the instance the user selected which is what I use to set
OLDAPPFOUND.  This value is definitely utilized by
RemoveExistingProducts as it only uninstalls the product matching the
product code in OLDAPPFOUND.

I have definitely reached the edge of my windows installer knowledge
here... :)

Thanks again for your help!

Amy

-----Original Message-----
From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Sent: Wednesday, September 02, 2009 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation

There's no connection between the property you put in your Upgrade
entries and what actually happens. I'm really very sure that OLDAPPFOUND
is for your information only - it doesn't drive anything, so changing it
won't affect anything. 

What you need to arrange is as previously suggested, have
MigrateFeatureStates set in the Upgrade entry for only that product you
want to migrate the features from. But your OLDAPPFOUND has a list of
products, and that makes me think you need more Upgrade entries. 

It might help if you posted your upgrade Xml. 

Phil Wilson

-----Original Message-----
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] 
Sent: Wednesday, September 02, 2009 12:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation

OK, so now I have MigrateFeatureStates actually doing something.
However, it is still attempting to migrate the features states from all
of the installed instances of my application.  The property listed in my
Upgrade table to use for storing the product codes to upgrade is
OLDAPPFOUND.  The action to set this to the single product code I am
interested in upgrading is SetOLDAPPFOUND, which is running directly
before MigrateFeatureStates.  From the verbose log:

Action 12:55:16: SetOLDAPPFOUND. 
Action start 12:55:16: SetOLDAPPFOUND.
MSI (c) (54:FC) [12:55:16:640]: PROPERTY CHANGE: Modifying OLDAPPFOUND
property. Its current value is
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'. Its new value:
'{009EC31E-E7DE-463B-94EB-9D24623563D8}'.
Action ended 12:55:16: SetOLDAPPFOUND. Return value 1.
MSI (c) (54:FC) [12:55:16:641]: Doing action: MigrateFeatureStates
Action 12:55:16: MigrateFeatureStates. Migrating feature states from
related applications
Action start 12:55:16: MigrateFeatureStates.
MSI (c) (54:FC) [12:55:16:641]: Migrating feature settings from
product(s)
'{20ED61C2-44DA-4CD4-AD05-DBE0F7ACAE7C};{1479021E-2170-497D-B05A-A4BFE94
0A624};{009EC31E-E7DE-463B-94EB-9D24623563D8};{F3E31D03-45F2-4733-B5C0-0
A4ED7B0D023};{23A8B2E0-6BF3-4369-A55F-6230744351DE};{82D91CB2-0C1E-4AAB-
949B-221F7EF4C12F}'

As you can see, although the OLDAPPFOUND property is set to the single
guid for the specific instance I care about, the MigrateFeatureStates
action is still using the list of guids detected during
FindRelatedProducts.

Any idea how I can change that list MigrateFeatureStates is working
with?

Thanks again!

Amy

-----Original Message-----
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] 
Sent: Tuesday, September 01, 2009 1:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation

Ah thank you!  I knew I must be missing something simple.

Amy

-----Original Message-----
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com] 
Sent: Tuesday, September 01, 2009 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] hoping for confirmation

Hi Amy,

Did you set UpgradeVersion/@MigrateFeatures to "yes" on product you want
to upgrade?

Alex




-----Original Message-----
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] 
Sent: Tuesday, September 01, 2009 9:28 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] hoping for confirmation

Hi All,

 

I am working on some minor issues in a major upgrade.  :)  I was hoping
someone could tell me a little about the MigrateFeatureStates action
when you have an installer that permits multiple embedded transforms of
the product code.

 

My install is in wix v3.  I have a custom action which modifies the
property I use to keep track of the product codes of already installed
applications (in the Upgrade table).  My property is OLDAPPFOUND.  With
verbose logging, I can see that the OLDAPPFOUND property gets set to a
series of product codes, one for each installed instance of my
application.  However, since I want to only upgrade one specific
instance, I later set the OLDAPPFOUND property to the product code for
the specific instance I want to upgrade.  This definitely works as I
want.

 

However, currently, I have my custom action SetOLDAPPFOUND scheduled
after MigrateFeatureStates in the InstallExecuteSequence.  The result
seems to be that despite what features were selected for install in the
product being upgraded, the install that runs for the new product is
trying to install all the features that are default selected when the
install begins.  I suspect this is related to the schedule of my
SetOLDAPPFOUND action relative to MigrateFeatureStates.  Can anyone tell
me if my suspicions are correct.  Would changing the schedule of these
two actions relative to one another make it so it would only install the
same features for the new app as it had for the old one?

 

Thanks,

 

Amy

 

Amy Rosewater VanMatre

SPECTRUM Human Resource Systems Corporation

707 17th Street Suite 3800

Denver CO, 80202

303.592.3403

arosewa...@spectrumhr.com

 

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to