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
