Just to be clear, the Windows Installer documentation says that only the first 3 fields of the the ProductVersion are used. You should be safe assuming that behavior. virtually, Rob Mensching - http://robmensching.com
On Sun, Oct 18, 2009 at 4:10 PM, Sascha Beaumont <sascha.beaum...@gmail.com>wrote: > Looks like I may have solved my own problem, assuming that I can rely > on Windows Installer continuing to ignore the fourth version field the > upgrade table below seems to prevent installation of two products with > the same upgrade code where only the fourth version field differs! > > <Upgrade Id="1C444740-BC30-11DE-8A1D-904F56D89593"> > <UpgradeVersion Property="OLDERVERSIONBEINGUPGRADED" > Maximum="$(var.version)" Minimum="0.0.0.0" > IncludeMinimum="yes" /> > > <UpgradeVersion Property="NEWERVERSIONDETECTED" > Minimum="$(var.version)" IncludeMinimum="no" > OnlyDetect="yes" /> > > <UpgradeVersion Property="ANOTHERBUILDINSTALLED" > Maximum="$(var.version)" Minimum="$(var.version)" > IncludeMinimum="yes" IncludeMaximum="yes" OnlyDetect="yes" > /> > </Upgrade> > > <CustomAction Id="CA_BlockInstall" Error="A different build is > already installed." /> > <CustomAction Id="CA_BlockOlderVersionInstall" Error="A newer > version is already installed." /> > > > I've done some testing with a barebones installer and this seems to > prevent all my "fourth version field" upgrade issues, meaning I can > switch to using Product/@Id="*" and (hopefully) prevent broken > installations. > > Now it should just be a matter of adding additional Upgrade elements > to handle the various SKU's. > > Thank you all for your help! If anyone can find fault with the above > method, please let me know :) > > > Sascha > > On Mon, Oct 19, 2009 at 8:59 AM, Sascha Beaumont > <sascha.beaum...@gmail.com> wrote: > > Rob, Blair, > > > > Thanks for your help. Looks like I need to reduce the number of > > component variations between my packages and look at auto-generating > > the ProductCode. > > > > One of the main reasons we chose to use a static product code for each > > release was that our regular builds only change the 4th field of the > > product version. Using a static product code means we get the "Another > > version of this product is already installed" > > > > Looking over the wix-users archives, there have been a few people > > trying to figure out how to permit a major upgrade when only the > > fourth version field has changed. Is there any way to *prevent* > > upgrade entirely if only the fourth version has changed, i.e. > > replicate the "Another version of this product is already installed" > > behaviour? If I can solve this issue, I believe I could move to an > > auto-generated ProductCode. > > > > Sascha > > > > > > > > On Fri, Oct 16, 2009 at 9:09 PM, Blair <os...@live.com> wrote: > >> Here is the answer: If you install two packages with the same > ProductCode > >> (and they have the same version) but the newer one is missing ANYTHING > that > >> the older has (with regard to components in features) you will end up > >> advertising your installation and orphaning your already installed > resources > >> (not a pretty sight). Basically it means you don't have the freedom to > have > >> per-language components (not even localized shortcut names). > >> > >> As a result, for your question #2, if you keep the same product code > between > >> your "Standard" and "Enterprise" packages, if someone installs your > >> "Standard" package "on top of" your "Enterprise" package you just broke > your > >> installation. > >> > >> Thus, the advice to have different product codes for each of those > different > >> "SKUs" you make (change it for kinds of packages, and change it for > >> languages). > >> > >> Here is how I generally implement the upgrade table in packages that I > >> intend to always "major upgrade" where I don't allow language > side-by-side > >> installations: > >> > >> <Condition Message="!(loc.BlockLanguageSwitch)">Installed OR (NOT > >> LANGUAGECHANGEDETECTED)</Condition> > >> > >> <Upgrade Id="$(var.UpgradeCode)"> > >> <UpgradeVersion Maximum="$(var.Version)" > >> MigrateFeatures="yes" > >> Property="OLDERVERSIONDETECTED"/> > >> <UpgradeVersion Minimum="$(var.Version)" > >> OnlyDetect="yes" > >> Property="NEWERVERSIONDETECTED"/> > >> <UpgradeVersion Minimum="$(var.Version)" Maximum="$(var.Version)" > >> IncludeMaximum="yes" IncludeMinimum="yes" > >> ExcludeLanguages="yes" Language="!(loc.LCID)" > >> OnlyDetect="yes" > Property="LANGUAGECHANGEDETECTED"/> > >> </Upgrade> > >> > >> And Product/@Id is always '*'. > >> > >> I will then either also block on NEWERVERSIONDETECTED or I will use > >> <CustomActionRef Id="WixExitEarlyWithSuccess" />, depending on > expectations. > >> > >> -----Original Message----- > >> From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] > >> Sent: Thursday, October 15, 2009 5:50 PM > >> To: General discussion for Windows Installer XML toolset. > >> Subject: [WiX-users] When to change Product/@Id (ProductCode)? - two > >> editions of the same product. > >> > >> Hi All, > >> > >> This isn't so much a WiX specific question, but more of a Windows > >> Installer one... however those on the list seem to have a pretty good > >> understanding of all the "rules" we should be following so I'm hoping > >> someone can point me in the right direction. > >> > >> Currently for our main product I'm using two Product/@Id with each > >> release - one for x86 and one for x64. However I'm using the *same* > >> Product/@Id and Upgrade/@Id for the 6 different languages we ship. > >> > >> Question 1 - Looking at "ProductCode Property" [ > >> http://msdn.microsoft.com/en-us/library/aa370854(VS.85).aspx ] I see a > >> requirement that the ProductCode must differ for different versions, > >> and languages. I'm just wondering why a different code for a different > >> language if I don't permit them to be installed side-by-side? The > >> packages are identical, we are just using Lingobit Localizer to > >> replace the resources in a pre-WiX build step and using a different > >> .wxl for the WiX build. > >> > >> Question 2 - Looking at "Changing the Product Code" [ > >> http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx ] I see > >> that adding new features is permitted without changing the product > >> code. However as the feature is only requested by a small portion of > >> our customer base... we're wanting to ship two versions of the same > >> MSI, one with the additional feature (which almost doubles the > >> download size) and one without. Should I be changing the product code > >> here or not? > >> > >> Effectively in Question 2 my aim is to distribute two editions of the > >> same product, prevent them being installed simultaneously, and permit > >> the user to upgrade from the "Standard" to the "Enterprise" release. > >> We always release major upgrades and so separating things into two > >> distinct product lines is a feasible one - I'm just trying to figure > >> out if I do so (different product codes, upgrade codes, etc) can I > >> prevent the user from installing one over the other just by using the > >> upgrade table? Or will I need some complicated CA's? > >> > >> Sascha > >> > >> > ---------------------------------------------------------------------------- > >> -- > >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA > >> is the only developer event you need to attend this year. Jumpstart your > >> developing skills, take BlackBerry mobile applications to market and > stay > >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! > >> http://p.sf.net/sfu/devconference > >> _______________________________________________ > >> WiX-users mailing list > >> WiX-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wix-users > >> > >> > >> > ------------------------------------------------------------------------------ > >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA > >> is the only developer event you need to attend this year. Jumpstart your > >> developing skills, take BlackBerry mobile applications to market and > stay > >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! > >> http://p.sf.net/sfu/devconference > >> _______________________________________________ > >> WiX-users mailing list > >> WiX-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wix-users > >> > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
