Because in our environment the fourth version is increased automatically with every build, how else would you differentiate from the "old" v1.1.1 and the "new" v1.1.1 ??
On Mon, Apr 12, 2010 at 6:02 PM, Viv Coco <vcotirl...@hotmail.com> wrote: > Hi Sascha, > > Thank you for your answer. > I understood your suggestion, but what it's not clear to me is why do > you actually have the 4th field in the version? I mean the approach you > have would have worked exactly the same also if your version number > would consist of only 3 fields, eg: 2.2.0, which doesn't get increased > for internal builds, only for releases to the customers. > What is the benefit of having also the 4th field in the version (in your > case)? > > Thx, > Viv > > > On 4/12/2010 3:57 AM, Sascha Beaumont wrote: >> You can't do this while also using Product/@Id="*", a product with the >> same version but different ID is seen as a different package. The best >> solution that I've come up with is to increase the fourth version >> field and block installation when the version number is the same. >> Windows Installer ignores the fourth field, so the two packages have >> effectively the same version. >> >> We then always increment one of the first three version fields as soon >> as a public release goes out. This means that the only people who ever >> see the 'error' message about another 'build' being installed are >> internal testers. >> >> One added benefit of this is that this means the QA team is testing in >> the same environment as our customers. We don't have to debug weird >> issues that only occur when a user installs one internal build on top >> of another. >> . >> Code: >> >> <Upgrade Id="$(var.Property_UpgradeCode)"> >> <UpgradeVersion OnlyDetect="yes" >> Minimum="$(var.version)" >> Property="NEWERVERSIONDETECTED" >> IncludeMinimum="no" /> >> >> <UpgradeVersion OnlyDetect="no" >> Maximum="$(var.version)" >> >> Property="OLDERVERSIONBEINGUPGRADED" >> IncludeMaximum="no" /> >> >> <!-- Detect for changes in 4th field only --> >> <UpgradeVersion Property="ANOTHERBUILDINSTALLED" >> Maximum="$(var.version)" >> Minimum="$(var.version)" >> IncludeMinimum="yes" IncludeMaximum="yes" >> OnlyDetect="yes" /> >> </Upgrade> >> >> <CustomAction Id="CA_BlockOlderVersionInstall" >> Error="!(loc.LaunchCondition_LaterVersion)" /> >> <CustomAction Id="CA_BlockAnotherBuildInstall" >> Error="!(loc.LaunchCondition_AnotherBuild)" /> >> >> <InstallExecuteSequence> >> <Custom Action="CA_BlockOlderVersionInstall" >> After="FindRelatedProducts"> >> <![CDATA[NEWERVERSIONDETECTED]]> >> </Custom> >> >> <!-- Prevent installation on 4th version field change only --> >> <Custom Action="CA_BlockAnotherBuildInstall" >> After="FindRelatedProducts"> >> <![CDATA[ANOTHERBUILDINSTALLED]]> >> </Custom> >> </InstallExecuteSequence> >> <InstallUISequence> >> <Custom Action="CA_BlockOlderVersionInstall" >> After="FindRelatedProducts"> >> <![CDATA[NEWERVERSIONDETECTED]]> >> </Custom> >> <Custom Action="CA_BlockAnotherBuildInstall" >> After="FindRelatedProducts"> >> <![CDATA[ANOTHERBUILDINSTALLED]]> >> </Custom> >> </InstallUISequence> >> >> >> Hope that helps :) >> >> >> >> On Fri, Apr 9, 2010 at 6:59 PM, Viv Coco<vcotirl...@hotmail.com> wrote: >> >>> Hi all, >>> >>> I am interested in doing only major upgrades in my installer, this is >>> why I have in the code for Product and Package the Id="*": >>> >>> [code] >>> <Product Id="*" Name="$(var.ProductName)" >>> Version="$(var.CurrentVersion)" Language="1033" >>> Manufacturer="$(var.CompanyName)" UpgradeCode="$(var.UpgradeCode)"> >>> <Package Id="*" InstallerVersion="301" Compressed="yes" /> >>> [/code] >>> >>> >>> It might happen that we freeze internally the release 2.2.0, I build a >>> package, give it to the QA they do tests, find bugs and those bugs are >>> fixed, so internally I have to do another msi package, with the same >>> version (2.2.0) but with the newer binaries (which contain the fix). In >>> this case I have to rebuild the msi package and I would like when the QA >>> installs it to (major) UPGRADE their already installed version 2.2.0 >>> even though the version is the same, but to get the new binaries. >>> >>> In order to achieve that, I wanted to have the upgrade table like: >>> [code] >>> <Upgrade Id="$(var.UpgradeCode)"> >>> <UpgradeVersion OnlyDetect="no" Property="OLDAPPFOUND" Minimum="0.0.1" >>> IncludeMinimum="yes" Maximum="$(var.CurrentVersion)" IncludeMaximum="yes" /> >>> <UpgradeVersion OnlyDetect="yes" Property="NEWAPPFOUND" >>> Minimum="$(var.CurrentVersion)" IncludeMinimum="no" /> >>> </Upgrade> >>> [/code] >>> >>> but I get the warning: >>> "warning LGHT1076: ICE61: This product should remove only older versions >>> of itself. The Maximum version is not less than the current product. >>> (2.2.0 2.2.0)" >>> >>> This is why, I changed to (IncludeMaximum="no"): >>> >>> [code] >>> <Upgrade Id="$(var.UpgradeCode)"> >>> <UpgradeVersion OnlyDetect="no" Property="OLDAPPFOUND" Minimum="0.0.1" >>> IncludeMinimum="yes" Maximum="$(var.CurrentVersion)" IncludeMaximum="no" /> >>> <UpgradeVersion OnlyDetect="yes" Property="NEWAPPFOUND" >>> Minimum="$(var.CurrentVersion)" IncludeMinimum="no" /> >>> </Upgrade> >>> [/code] >>> >>> and I was able to install the same product TWICE which is of course not >>> what I wanted. >>> >>> Can smbd tell me how could I get what I want: >>> - to NOT have the same product installed twice >>> - to (major) UPGRADE the same version of the product (same version, but >>> different msi package with different binaries) >>> >>> Thx, >>> Viv >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
