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
