I believe it is the first time a given 'Product Code' is installed (not 100% certain).
I didn't believe that the FindRelatedProducts and RemoveExistingProducts actions had much of anything to do with a small update or minor upgrade delivered via an MSI because these scenarios are still reinstalls. But before I said so, I thought I should confirm that so I built and tested my first ever minor upgrade (MSI based). When run with logging this is confirmed... msiexec /i %my.msi% /l*v log.log REINSTALL=ALL REINSTALLMODE=vomus MSI (c) (F8:04) [16:03:42:699]: Doing action: FindRelatedProducts MSI (c) (F8:04) [16:03:42:699]: Note: 1: 2205 2: 3: ActionText Action 16:03:42: FindRelatedProducts. Searching for related applications Action start 16:03:42: FindRelatedProducts. ==> MSI (c) (F8:04) [16:03:42:699]: Skipping FindRelatedProducts action: not run in maintenance mode Action ended 16:03:42: FindRelatedProducts. Return value 0. . . . MSI (s) (BC:78) [16:03:43:120]: Doing action: RemoveExistingProducts MSI (s) (BC:78) [16:03:43:120]: Note: 1: 2205 2: 3: ActionText Action 16:03:43: RemoveExistingProducts. Removing applications Action start 16:03:43: RemoveExistingProducts. ==> MSI (s) (BC:78) [16:03:43:120]: Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall Action ended 16:03:43: RemoveExistingProducts. Return value 0. I would expect the WiX CA's to behave correctly in patch, upgrade, uninstall, etc... scenarios (so if you're referring to WiX CA's for SQL items, websites, etc...) and your RemoveExistingProducts action is schedule appropriately (in an upgrade scenario), I believe that is a correct assumption to make (not saying there couldn't be bugs lurking somewhere, though [but I like to remain positive :) ]). -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien Sent: Thursday, September 11, 2008 3:29 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate v1.0 -> v1.1 patch msp minor upgrade msp wix sources Thanks for the responses. When folks on the dll state that FindRelatedProducts and RemoveExistingProducts "only runs the first time the product is installed" do they mean only the first time a specific msi version of a product is installed? Put another way if I having nothing on the system and run the v1.0 msi FindRelatedProducts and RemoveExistingProducts run with the latter only running if I have explicitly added it to my InstallExecuteSequence. Now I come along and on that same system with v1.0 installed run the v1.1 msi in which case is this considered the first time the v1.1 product is being installed or the second time the vwhatever release of the given product is being installed. As for components/custom actions I don't want to rerun during the second pass such as database create, script and related custom actions sounds like if I get my v1.1 minor upgrade msi and v1.1 minor upgrade patch msp output correct I don't explicitely have to worry about them provided in the case of components that their KeyPath is properly detected during the upgrade or patch processing and in the case of custom actions I've have the correct install pass only feature & component state conditions in place. Is that a correct assumption. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga Sent: Thursday, September 11, 2008 1:18 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate v1.0 -> v1.1 patch msp minor upgrade msp wix sources FindRelatedProducts: http://msdn.microsoft.com/en-us/library/aa368600(VS.85).aspx ... only runs the first time the product is installed. As so, I don't believe it executes during a patch scenario (so it wouldn't be relevant). That is also documented as being true for RemoveExistingProducts (only runs the first time the product is installed); so not relevant for a patch scenario. Having never delivered a small update or minor upgrade with an MSI, I can't answer those questions. Hopefully folks with experience in this area will chime in. Regarding all v1.0 product components not conditioned with an UPDATINGPRODUCTCODE setting will be removed; I'm not familiar with that. The way I've understood placement of RemoveExistingProducts post InstallFinalize has to do with component rules: Simple example: V1.0 Installs: Foo.dll v1.2.0 Foobar.dll v1.2.0 V2.0 Installs: Foo.dll v1.2.3 When V1.0 is installed, Foo.dll and Foobar.dll are installed. When the upgrade to V2.0 is performed, Foo.dll is updated to v1.2.3 and the ref-count is incremented for the component. InstallFinalize takes place, then the removal of V1.0 takes place. Foo.dll's component is de-refcounted but since a product is still using it (V2.0) the file remains (v1.2.3). Foobar.dll gets removed. Custom actions should determine what to do based upon a related component state. If you had a DB removal action tied to the removal of Foo.dll, in the above scenario that action would be not executed (if it was conditioned upon Foobar.dll, it would be executed). -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien Sent: Thursday, September 11, 2008 2:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate v1.0 -> v1.1 patch msp minor upgrade msp wix sources Does inclusion of msi minor upgrade wix sources in v1.1 msi block the ability to also generate patch msp minor upgrade msp wix sources? For example does having the following product.wxs sources prevent me from also being able to generate a v1.0 -> v1.1 patch msp minor upgrade msp wix sources? <Upgrade Id="D1652FA2-32AC-4D5B-8DCF-5DF11FE128BA"> <UpgradeVersion Minimum="1.1.0.0" IncludeMinimum="no" OnlyDetect="yes" Property="NEWERVERSIONFOUND" /> <UpgradeVersion Minimum="1.0.0.0" IncludeMinimum="yes" Maximum="1.1.0.0" IncludeMaximum="no" Property="OLDERVERSIONFOUND" /> </Upgrade> <CustomAction Id="PreventDowngrading" Error="Newer version already installed." /> <CustomAction Id="SetUpgradeReInstallProperty" Property="REINSTALL" Value="all" /> <CustomAction Id="SetUpgradeReInstallModeProperty" Property="REINSTALLMODE" Value="vomus" /> <InstallUISequence> <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWERVERSIONFOUND</Custom> </InstallUISequence> <InstallExecuteSequence> <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWERVERSIONFOUND</Custom> <Custom Action="SetUpgradeReInstallProperty" After="FindRelatedProducts">OLDERVERSIONFOUND</Custom> <Custom Action="SetUpgradeReInstallModeProperty" After="FindRelatedProducts">OLDERVERSIONFOUND</Custom> <RemoveExistingProducts After="InstallFinalize" /> Also evertying I read about the <RemoveExistingProducts After="InstallFinalize" /> action suggests that it causes all v1.0 product components not conditioned with an UPDATINGPRODUCTCODE setting to be removed after the v1.1 release has been installed provided REINSTALL=all REINSTALLMODE=vomus are set. What is really confusing me about this is if that's the case how do all these minor and major upgrade server deliverable msi's work that take you from a prior release to the next release w/o doing things like dropping databases or iis site and vdir settings during minor/major upgrade processing? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
