The upgrade code is the same. You know, for some odd reason I was just going to try a 3 field version instead of 4 and then you mentioned this. My versions are like 1.0.0.1 and 1.0.0.2... I just figured if it was smart enough to know that something had changed (because it wasn't asking me for repair/remove) that it must be able to recognize the versions were different. Just tried it out and sure enough it works with 3-field versions (even with my original launch condition logic). Now if I could only get the last 10 hours of my life back!
Thanks! On Thu, Dec 17, 2009 at 11:06 PM, Sascha Beaumont <sascha.beaum...@gmail.com> wrote: > Is the upgrade code set correctly? Generally the upgrade code should > be the static over the lifetime of your product, it's the one thing > that doesn't change between versions, builds, etc. > > Also note that Windows Installer only recognizes the first three > fields of a version number for MSI packages, i.e. 1.0.0.1 and 1.0.0.2 > both appear as 1.0.0 to Windows Installer. (the fourth digit is only > used for file versions, for packages it can be present but is ignored) > > In the sample code I posted, the action is scheduled to occur directly > after "FindRelatedProducts" - the FindRelatedProducts action is what > would actually search the upgrade table and set NEWERVERSIONDETECTED > and OLDERVERSIONDETECTED... can you tell from the logs if this action > is being executed? > > Sascha > > On Fri, Dec 18, 2009 at 1:45 PM, Jason T. <jt2...@gmail.com> wrote: >> Thanks for the response. I had not tried a custom action, but I did >> just now. Same problem, doesn't do anything. When I go through the >> logs the NEWERVERSIONDETECTED and OLDERVERSIONDETECTED properties are >> not getting set. Therefore the conditions are false and the custom >> action never runs. I know very little about WiX and MSIs in general, >> but in the past when I used a custom action I had 1 action for setting >> the property and a second action that actually used that property. Do >> I need to do something like that? It just seems that the upgrade >> stuff isn't getting "executed" currently. >> >> >> On Thu, Dec 17, 2009 at 6:56 PM, Sascha Beaumont >> <sascha.beaum...@gmail.com> wrote: >>> Have you tried using a custom action, instead of a launch condition to >>> block install? >>> >>> e.g. >>> >>> <Upgrade Id="$(var.Property_UpgradeCode)"> >>> <UpgradeVersion OnlyDetect="yes" >>> Minimum="$(var.version)" >>> Property="NEWERVERSIONDETECTED" >>> IncludeMinimum="no" /> >>> >>> <UpgradeVersion OnlyDetect="yes" >>> Maximum="$(var.version)" >>> Property="OLDERVERSIONDETECTED" >>> IncludeMaximum="no" /> >>> </Upgrade> >>> >>> <CustomAction Id="CA_BlockInstall" Error="!(loc.MyError)" /> >>> >>> <InstallExecuteSequence> >>> <Custom Action="CA_BlockInstall" After="FindRelatedProducts"> >>> <![CDATA[NEWERVERSIONDETECTED Or OLDERVERSIONDETECTED]]> >>> </Custom> >>> <LaunchConditions After="AppSearch" /> >>> </InstallExecuteSequence> >>> >>> <InstallUISequence> >>> <Custom Action="CA_BlockInstall" After="FindRelatedProducts"> >>> <![CDATA[NEWERVERSIONDETECTED Or OLDERVERSIONDETECTED]]> >>> </Custom> >>> <LaunchConditions After="AppSearch" /> >>> </InstallUISequence> >>> >>> >>> >>> On Fri, Dec 18, 2009 at 9:44 AM, Jason T. <jt2...@gmail.com> wrote: >>>> Hello, >>>> >>>> I'm trying to detect when a different version of my package has >>>> already been installed so that I can abort the installation. I'm not >>>> looking to do the "major upgrade", I just want to abort if either an >>>> older or a newer version is found (if the version is the same the >>>> repair/remove logic already functions correctly). I have added this: >>>> >>>> <Upgrade Id='$(var.UpgradeCode)'> >>>> <UpgradeVersion OnlyDetect='yes' Minimum='$(var.ProductVersion)' >>>> Property='NEWERVERSIONDETECTED' IncludeMinimum='no' /> >>>> <UpgradeVersion OnlyDetect='yes' Maximum='$(var.ProductVersion)' >>>> Property='OLDERVERSIONDETECTED' IncludeMaximum='no' /> >>>> </Upgrade> >>>> >>>> <Condition Message="Another version of this package is already >>>> installed, you must uninstall that first.">(NOT NEWERVERSIONDETECTED) >>>> AND (NOT OLDERVERSIONDETECTED)</Condition> >>>> >>>> This seems to have no effect however, both older and newer versions of >>>> the package (as defined by var.ProductVersion) are allowed to install >>>> on top of the existing version (multiple entries then appear in >>>> Add/Remove Programs). I also played around with different things in >>>> the InstallExecuteSequence and InstallUISequence sections, for example >>>> >>>> <FindRelatedProducts Before='LaunchConditions' /> >>>> >>>> But this doesn't seem to do anything either. When I log the installs >>>> I don't see NEWERVERSIONDETECTED or OLDERVERSIONDETECTED being set to >>>> anything. >>>> >>>> What am I missing? Or, conversely, is there a simpler way to do what >>>> I am trying to do? >>>> >>>> Thanks! >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> 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 Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> 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 Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> 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 Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
