Hi,
I have a scripted custom action to register a COM+ service on install and
unregister it during uninstall.
It works fine during install, but fails during uninstall.
Custom Action code to unregister
-
CustomAction Id=Propca_UnReg_Assembly
Thank you and my apologies for not including this critical information. I
am using WixUIExtensions so this is a graphical, interactive installation.
My UI is a modified version of WixUI_InstallDir.wxs.
I did verify that the problematic directory is not created until after you
confirm
Bug in WiX v3.9: http://wixtoolset.org/issues/4609/
See comments in the bug for details.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Patrick Pirzer
Thanks for the help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BindPath-and-supporting-patches-tp7598792p7598799.html
Sent from the wix-users mailing list archive at Nabble.com.
There a couple of questions in this thread. Regarding what's
installed, don't trawl the registry looking for clues, trawl the
documentation instead. MsiEnumProducts() will list what's installed.
MsiGetProductInfo() will tell you details about a specific installed
product, just to use two examples
Wix Toolset 3.10
If I install my application in a directory with spaces (C:\Program Files,
C:\My Apps) an extra directory is created (C:\Program or C:\My).
Running msiexec with /l*vx doesn't show any trace of this directory being
created in the log file.
Can anyone help me to debug? Or make any
Wix Toolset 3.10
During my installation UI process, I ask the user for the installation
directory of an existing product. I use the executables from this product
in the creation of my shortcuts. This works perfectly as I can use the
variable recuperated from my custom UI dialog in the target
Property Id=WIXUI_INSTALLDIR Value=INSTALLDIR/
And WixUI_InstallDir.wxs is the same as the original:
Publish Dialog=InstallDirDlg Control=Back Event=NewDialog
Value=UserRegistrationDlg1/Publish
Publish Dialog=InstallDirDlg Control=Next Event=SetTargetPath
Value=[WIXUI_INSTALLDIR]
That's incorrect. It is totally valid to provide a Name attribute on a
well-known folder.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: John Cooper
Because when I started with WiX I read this:
http://wix.tramontana.co.hu/tutorial/getting-started/the-files-inside
I removed these overrides but the issue remains:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder'
Directory Id='INSTALLDIR'
That's enough. Unnamed bind paths are supported by pyro.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday,
No. smile/
Arguably better design would be to have the BA do what the syscheck.exe does
(during detection or so).
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Rick
I have a utility application that evaluates the install target / system… it's
the ExePackage in the included example. Following the system assessment, a
registry entry is written that I would like to use to install one or more .msi.
Is there a way to do the RegistrySearch after ExePackage and
?We have an installer containing a service and an accompanying tray icon
application. There seems to be a problem when unistalling this application if
both are running, and the installer has a UI (yes, that is one of the
determining factors).
Sample project reproducing the issue:
How are you passing it to the installer? If on the command line, the directory
path needs to be delimited.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
If it's done right, it shouldn't make a difference whether it is command line
or UI driven.
How is it set and what is the value of WIXUI_INSTALLDIR Property?
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates,
OK, your WIXUI_INSTALLDIR is fine.
This is the source of your problem:
Directory Id=ProgramMenuFolder Name=Programs
Why are you overriding this pre-defined value? By doing so, its functionality
is destroyed. Remove the Name attribute.
Liikewise, why are you overriding ProgramFilesFolder?
This is going to turn into a blog post, I know it.
0. First, at this point in WiX v3.x deprecated means the functionality will
not be present in WiX v4.x. There are no breaking changes in WiX v3.x (unless
we need to for security purposes). You can keep doing what you're doing as long
as you're
I'm not saying its invalid. I want to know the design decision behind it.
Most of the time, I'm using ProgramMenuFolder to stick entries in the menu. I
can move the path to that around, and it is perfectly valid, but I can't expect
the functionality of adding a menu entry to work when I have
I do not know if this is possible (and if the exe is designed to be a service
and interacts with the SCM, then one wonders why it was not installed as a
service). But if I were trying register an existing file as a service, I
would ditch the Wix\File element (which should get rid of the light
Thanks John.
I don’t understand why you specifically think it's ProgramMenuFolder? When
the name was Programs and I installed to C:\My Apps it still created
C\My .
Paul
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: January 9, 2015 14:37
To: General
Hi,
Currently i am trying to create slide show animation during installation. I
have some following queries.
How can i add a billboard control to the standard ProgressDlg ? Where
exactly in the wix .. element i have to do this? Which exact element i
have to use?
I have read some forum that to
It's really funny, because just my project manager has this problem.
And the joke is: We are testing on the same machine.
Maybe overridable self-defined Bootstrapper-variables shall be just setted in
the Plan-method.
I will try that now.
-Ursprüngliche Nachricht-
Von: Phill Hogland
I have following Wix File that is supposed to install the contents in
C:\SampleProgram . The generated msi is supposed to be installed as msiexec
/i installer.msi IPADDRESS=1.1.1.1. The parameter IPADDRESS is fetched by
Custom Action that will make a config file as below in the folder where
Okay, now i have found out, why this error happens.
I had WiX 3.8 (all things fine) and my project manager has WiX 3.9.
Now i installed WiX 3.9, made a rebuild of my solution and tested the setup.
Here the result from the log file:
[0E54:0B54][2015-01-09T12:40:17]i299: Plan complete, result: 0x0
Hi All,
I am trying to find out something. I hope you can help. I was wondering how
does the msi
keep a track of the fact that the product has already been installed. I
will explain the issue in detail.
For eg:- When I install product.msi with
There is a discussion about supporting 'patching' here
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-patches-using-wixout-bf-flag-deprecated-td7598765.html
and I have a followup question, but slightly different focus.
I use File elements like this
File KeyPath=yes
Hello All,
I found that the entries are in the Windows Upgrade Table.
http://msdn.microsoft.com/en-us/library/aa372379%28v=vs.85%29.aspx
Is there a way to view this table from C# code and add or delete some
entries?
From: Prantik [mailto:prantik.sar...@grapecity.com]
Sent: 09 January
Sorry for earlier question, it was sent as mistake.
I have following Wix File that is supposed to install the contents in
C:\SampleProgram . The generated msi is supposed to be installed as msiexec
/i installer.msi IPADDRESS=1.1.1.1. The parameter IPADDRESS is fetched by
Custom Action that will
Thank you all for suggestions! Truly appreciate all the help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-built-for-AnyCPU-does-not-read-64-bit-registry-hive-tp7598754p7598793.html
Sent from the wix-users mailing list archive at
30 matches
Mail list logo
