Hello!I need to create a patch script that will update a product. The problem is that product was already installed with msi script that has no UpgradeCode in element Product.Is it possible to create a patch if element Product in installation msi script is missing attribute UpgradeCode? How?
I've recently started looking at the WiX toolset and have come across a
requirement I can't seem to get round, I'd be grateful for any hints
that might help.
I have a custom action that I want to execute only at installation and
only if a particular feature has been chosen for installation.
You need to make the custom action conditional based on the Installed or REMOVE properties (depending on your exact requirements), and on the Feature syntax.
Something like this, maybe:
Custom Action="" After=InstallFiles(NOT Installed) AND (MyFeature=3)/Custom
Prefixing onto the feature name
Hi,
I have a specific requirement as follows
I have to get more than one paths
of some directories using browse dialog.
I need to put some files into those
paths.
Then I have to set those paths
as values of some environment variables.
I could not understand how
How do you know it's not firing? Does it say so in the log, or is there some
other behaviour you're
expecting to see. I only ask because it might be affected by something you
haven't thought of. Log
the install and see what it says. It should fire fine.
Rob
WayneBoyles wrote:
Sorry
See this post
http://article.gmane.org/gmane.comp.windows.devel.wix.user/9484
This dialog example shows how to set a property from a browse dialog. You can
set a Directory Id to
be the same as the property and have it updated. You can then put your file
components in here.
You can also use
Hi,
I installed the snapshot 3.0.1910.0 and tried to use the
method specified with feature request #1503405.
d:\proj\Windows Installer XML\light.exe
-dWixUILicenseRtf=d:/keylog.txt /nologo /v0 /b myoutputpath (all my
wixobjs) -ext WixUIExtension -cultures:de-de
If I use the 'old' method by
Hello,
following is missing in the German localization to compile with
WixUI_InstallDir
line 75: String Id=InstallDirDlgBrowseSamp;uchen.../String
i work with the latest weekly release version 2.x
could somebody add this to the source?
Regards
Alex
We have an existing Wix installer that basically just takes
a set of .NET assemblies and deploys them to various folders on the machine
into the \Program Files\AppName folder by default. There are a few registry
settings under HKLM\Software\AppName that are written as well.
On a 64-bit
Kelly Summerlin wrote:
My question is this, is
it possible to use the same Wix
files to build one MSI that will deploy the files and registry settings
to
32-bit or 64-bit determined at runtime?
No. An MSI package must be marked as 64-bit before it can install
64-bit
Since most of my Wix code is just
component definitions though it looks like Ill need separate
sources for the 64-bit component definitions and the 32-bit
component definitions since the Win64 attribute marks them as 32-bit or
64-bit, correct? In the Wix documentation for component Win64
I've just installed Votive on our build machine (a Windows 2000 machine)
and compiled a wxs file. Two things happen:
1. The compiler reports that it is version 2.0.2328 even though I used
the votive-2.0.4221.0 installer. This same installer has installed
v2.0.4221 on an Windows XP machine.
Please update to the latest WiX 3.0 release. This error is due to
installing the WiX tools in a path with spaces and it has been fixed in the
latest releases.
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Klimek Manuel
Sent: Monday, July 24,
Kelly Summerlin wrote:
So it sounds like here that I should have separate GUIDs for 32-bit and
64-bit component definitions even though the assemblies that are being
deployed are exactly the same. If this is the case, then I can
understand the need for separate GUIDs, but it sure makes
Hi,
Can anyone tell me what the following error message from the Orca
Validator means:
ICE43 ERROR Component PROGUID_comp has non-advertised shortcuts. It
should use a registry key under HKCU as its KeyPath, not a file.
??
Thanks,
John
John Calcote wrote:
Hi,
Can anyone tell me what the following error message from the Orca
Validator means:
ICE43 ERROR Component PROGUID_comp has non-advertised shortcuts. It
should use a registry key under HKCU as its KeyPath, not a file.
??
I tend to ignore that one. It
That means that the component needs to have a registry key under HKCU as its
keypath. This supports installation of per-user shortcuts for a per-machine
installation.
Alternatively, you could switch to advertised shortcuts by specifying
Advertise=yes on the Shortcut elements. However,
It's a very good question actually and I've seen no solid recommendation on
a best-practice approach. I think you can create any HKCU registry key you
like and use it as the keypath (so long as each component has a different
key). This issue comes up often so I'll see if I can learn more, but
Derek,
Okay, the subtle approach didn't work. Now I'll try the less subtle
version of my question ;-)...
I don't really understand how a registry key is associated with a
shortcut - shortcuts are files in the file system, not registry keys,
AFAIK. This is a more fundamental question. Perhaps it
I believe it needs to look something like the following pseudo-code:
Component
Registry Root=HKCU KeyPath=yes ... /
Shortcut ... /
/Component
Basically, what you need to do is create a component with an HKCU registry
key as its keypath and the shortcut. When MSI does a health check on the
Derek Cicerone wrote:
That means that the component needs to have a registry key under HKCU as its
keypath. This supports installation of per-user shortcuts for a per-machine
installation.
I don't see why anyone would ever want to do this - put per user shortcuts in
per user installations
Bob Arnson wrote:
[snip]
Running arbitrary code during installation is bad. It's
self-reg, except
worse. The entire design of MSI is based on the idea of
describing your
setup and letting MSI interpret the description. Running code
is bad and
should be avoided whenever possible.
You make a good point about the ProgramMenuFolder directory - I agree that
ICE43 seems overzealous in some cases. However, during ICE validation,
there is no way to know if an MSI file will be installed per-user or
per-machine (since the value of ALLUSERS may be set at the last moment). So
the
John,
I don't think it's fair to say that you should NEVER run your own code.
I believe the spirit of the thing dictates that you use MSI data
wherever you can, and write code for exactly what you can't do with MSI.
Clearly, there's a need for this. Microsoft could never anticipate every
possible
Derek,
Thanks, this is the info I needed.
John
Derek Cicerone [EMAIL PROTECTED] 7/24/2006 5:21 PM
I believe it needs to look something like the following pseudo-code:
Component
Registry Root=HKCU KeyPath=yes ... /
Shortcut ... /
/Component
Basically, what you need to do is create a
25 matches
Mail list logo
