1. Agreed. I find it easier to change UpgradeCodes, rather than do the
UpgradeVersion dance. In my mind, I think about UpgradeCodes as defining
whether the package installs SxS or not.
2. You can override the default planning of Burn for packages by returning
your requested state for that
Or use MajorUpgrade element. smile/
On Wed, Jul 11, 2012 at 12:36 PM, Don Walker don.wal...@versaterm.comwrote:
Chad Petersen wrote
I was able to get past this error in your example by adding this inside
the Fragment
InstallExecuteSequence
RemoveExistingProducts
Rob Mensching-7 wrote
Or use MajorUpgrade element. smile/
I don't think that the MajorUpgrade element gives me the flexibility that I
need. My assumptions (and what I believe to be best practice) are:
1. The UpgradeCode is fixed for all versions of the product.
2. The Product Id is set to
Don Walker wrote
Here is the situation:
1. We allow multiple versions of our product to be installed at the same
time if they have a different Major.Minor version. I don't believe that
the MajorUpgrade element supports this option. The UpgradeVersion elements
shown should provide for
In WiX version 3.6.3109.0 I am getting the following build error:
Product.wxs(16,0): error LGHT0094: Unresolved reference to symbol
'WixAction:InstallExecuteSequence/RemoveExistingProducts' in section
'Product:*'.
The same error appears for line 18.
My test example follows:
?xml version=1.0
, 2012 8:49 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug? UpgradeVersion element causing LGHT0094 error
In WiX version 3.6.3109.0 I am getting the following build error:
Product.wxs(16,0): error LGHT0094: Unresolved reference to symbol
'WixAction:InstallExecuteSequence
Chad Petersen wrote
I was able to get past this error in your example by adding this inside
the Fragment
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
Scheduling RemoveExistingProducts worked for me too. Ironically, I had just
7 matches
Mail list logo
