I have a WiX package that should always deliver files, but should only
uninstall the files when a condition is met. The condition is that common files
should not be uninstalled if another version of the product is installed (we
are not supporting true upgrades, our upgrade is installing the
Associates, Inc.® | Lenexa, KS 66214 | Ext:
431050 |jocoo...@jackhenry.com
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 19, 2015 4:30 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Deliver File
Is there any easy way to deliver a file with a different name?
I have:
Component Id=readme.txt Guid=*
File Id=readme.txt KeyPath=yes
Source=$(var.PATH_TO_PROJ)viewer.readme.txt /
/Component
And I need to deliver the viewer.readme.txt file as readme.txt.
Is there an easy way to do this
This is probably more of a coding-style question, but what's the best approach
to reusing C# (or other) custom actions that use properties?
Is it better to have a separate method for each declaration of the custom
action that access properties specific to that declaration and use a common
I have the following component that has an Auto-Generated GUID. I am seeing
that every build, however, the GUID is the same. I've tried different things,
such as:
-Having a DirectoryRef to a directory besides the TARGETDIR
-Setting KeyPath on the component
-Setting
The GUID is generated based on the source path so if it did not change then
the generated GUID will have the same result (appear to be the same GUID),
which is fine in most situations when a Component has a single resource.
The source path? I'm confused there. I have registry entries so they're
I've looked high and low, and there's not much discussions about unit testing
custom actions.
Does anybody have a strategy for this?
My initial thought was to refactor my code so that any Session references occur
outside of the scope of what I'm testing, but that no longer works for some of
the paths so that the *
component IDs get updated for each version. You'll also need to deploy them
to a version specific installation folder.
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 11:22 AM
?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 10:45 AM
To: General discussion about
say why you need a unique UpgradeCode
all the time.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham
Notification Service Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext:
431050 |jocoo...@jackhenry.com
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 10:27 AM
To: wix-users
compatibility) by using a manifest to do
Reg-Free COM. If you need to add a manifest without rebuilding the application,
mt.exe from the Windows SDK's can do that.
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May
I'm understanding now that I can use the MajorUpgrade element while providing a
UpgradeCode to achieve what I need. I'm just not sure from the documentation
yet.
What attributes do I need to include for the MajorUpgrade element? I looked at
the documentation and it isn't immediately clear to
ability, but that's not the case. I have added the UpgradeCode but left out the
MajorUpgrade element.
Christoph
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
Sent: Tuesday, May 26, 2015 2:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users
.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 11:33 AM
I am getting the following error for my project:
The Product/@UpgradeCode attribute was not found; it is strongly recommended to
ensure that this product can be upgraded.
I am WELL aware of the following:
1) You should always have an upgrade code, even if you don't plan on
upgrading. But
...@jackhenry.com
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 10:27 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Hiding UpgradeCode Attribute Warning
The e-mail below is from an external source
17 matches
Mail list logo
