MigrateFeatureStates checks records in the Upgrade table. It completely ignores your OLDAPPFOUND property. This property is just for use in conditions. Also, keep in mind that usage of MigrateFeatureState is limited (http://msdn.microsoft.com/en-us/library/aa370034(VS.85).aspx):
"... The method is only useful when the new feature tree has not greatly changed from the original." I am not sure I completely understand you scenario, but it looks like you need: - separate property for each product being upgraded - schedule FindRelatedProducts before InstallValidate - Set conditions on features appropriately using Upgrade table properties or run custom action(s) to get the installed features and update ADDLOCAL/ADDSOURCE (haven't tried the ADDLOCAL/ADDSOURCE approach - need to be tested). -----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
