Hi,
we use the pskill.exe tool from sysinternals, packed into the setup as a
binary. That works on all kind of windows machines.
Another problem though, if you kill the process, that displays the tray-icon,
the tray-icon will stay where it is until the mouse is moved over it. But
that's a
Hi,
in our x64 Setup we write some registry keys to the native registry hive, using
this pattern:
RegistryValue Id='EWS.User.Path' Root='HKLM' Key='Software\XXX\XXX'
Name='UserExePath' Action='write' Type='string' Value='[User]User.exe' /
On uninstall those keys are removed, but I do not want
Hi,
this code starts a custom action called _CA_installscript after starting up
services. It is only executed, if $C__installscript-Variable/Funktion returns
a value greater then 2.
For better Help on this, you should provide more of the code.
Regards,
Oliver
From: [EMAIL PROTECTED]
2007 04:48
To: Mailinglist; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Using .NET 2.0 Managed Custom Actions
I read and tested the Hosting the CLR with a custom action. It is great to
bridge between the unmanaged CA and managed CA. However, it cannot work with a
deferred CA. Right
Well, I think that installers should not do anything user-specific.
Installer may copy files to the All-Users profile, and the software itself
should go on an copy those files to the user who startet the software.
What about the installer install necessary files for the software, to one user,
why I set the property tu UNAME in
this example.
Oliver
From: salome zk [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 12. September 2007 17:25
To: Mailinglist; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] save username and password
How can i access the username that i have saved
Well, I do have the same problem, specially when it comes to votive.
The files must be duplicate, to be used in two projects, linking to files in
another project is not possible.
That leads to much redundant code and a big overhead for maintaining that.
In our Solution we have a client and a
:[EMAIL PROTECTED] On Behalf Of Mailinglist
Sent: Tuesday, September 11, 2007 12:41 AM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE: Re: [WiX-users] Managed custom action return values
Hi,
To say writing managed custom actions is not supported is a rather broad
brush statement
Hi Marcel,
The reason I have to put my files at this specific location is that I am
writing an installer for an existing opensource tool (maven) which expects
certain files in this exact location.
Well, since it is open source, you could easily solve the problem at the
source. How does maven
Hi,
even if you use a custom action to encrypt and decrypt the credentials, it
would be unsafe to store them, cause they coud be found and decrypted.
The data you store can be hacked on (RegistryKeys, File) as well as your code
that you use to store/encrypt/decrypt them. If you use tools,
Hi Salome,
you can store the username in the registry (but only the username) in a key
that is not by default deleted on uninstall.
Oliver
From: salome zk [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 12. September 2007 14:46
To: Mailinglist; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users
Hello,
Writing managed custom actions is not supported. A standalone executable will
not see anything of the setup around.
I took two half ready projects and used them, to build up something that gives
you the possibility to write managed custom actions and access the current
setup from
Hi,
We use a variable with current build passed into wix.
Therefore you can enter Build=$(Configuration) on the Build/Link Tab of the
.wixproj properties page.
With that, you are able to add debug stuff like this:
Component Id=MyFile' Guid=*MAKESOMEGUID*
File Id=MyFile.exe' Name='MyFile.exe'
Try it like this:
CustomAction Id=installMTMAgentService Directory=pythonD0
ExeCommand=[#python.exe] [#service.pyc] install /
Oli
- Original Message -
From: Matthieu RUNTZmailto:[EMAIL PROTECTED]
To: Mark Linemailto:[EMAIL PROTECTED]
Cc:
Hi,
please make sure, that python.exe equals the id-tag of that file in your
setup.
If your file-tag looks like this:
File Id='python' Name='python.exe' Source='[INSTALLDIR]bin\' Checksum='yes' /
Then the custom action should look like this:
CustomAction Id=installMTMAgentService
Hi,
you want to launch the custom action, that assigns E:\ to TARGETDIR only if
TARGETDIR has the value E:\. Your Condition is wrong.
In our setup we use a Property that determines if drive e is present and if so,
sets the default install path to e, maybe this is something for you either.
Bob Arnson wrote:
That looks fine but the sequencing you give in an earlier message means
that any directory chosen by the user will be overwritten by your
DirectorySet custom action. You want to add a condition -- NOT TARGETDIR
-- so it doesn't run if the user has already specified one in the
Hi Craig,
Is there a way to call RemoveFolder, and have it remove (and empty) all
sub-folders? My uninstall is using RemoveFile/RemoveFolder on a folder
(which contains files created after installation), but since some of the
files are stored in sub-directories, the uninstall leaves the
Mailinglist wrote:
The directory causing the error is the TARGETDIR. The root path of the
installation and yes, the main component has a CreateFolder tag for it.
Stop, I've just seen that I turned facts. The one MergeModule with the
IisExtension gets its folders createt in the right path
Hello Bob,
When we come to the InstallDirDlg, the directory is shown correctly, if the
DirectorySet ca is run early enough. If the user now wishes to customize this
path, I get an error 2707, that the path does not exist, when I start up the
BrowseDlg.
Error 2707 includes the directory
Hello Bob,
When we come to the InstallDirDlg, the directory is shown correctly, if the
DirectorySet ca is run early enough. If the user now wishes to customize this
path, I get an error 2707, that the path does not exist, when I start up the
BrowseDlg.
Error 2707 includes the directory
Hello again,
I now have the problem, that in our setup we first search if drive e: is
present and set the TARGETDIR-Property to a folder on e: otherwise c:.
This is done like this:
Property Id='NEWINSTALLDIR' Value='C:\'
DirectorySearch Id='MSEwsDefaultInstallRoot_Search' Path='E:\'
Hello,
I try to push a commandline given parameter from my setup to one of my
mergemodules with a custom action. This parameter should trigger a custom
action from the mergemodule.
However, in the log, the property for the parameter in main setup is shown and
set correctly in the msi logfile,
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kalle Olavi
Niemitalo
Sent: Dienstag, 10. Juli 2007 11:20
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Passing Properties to Mergemodules
Mailinglist [EMAIL PROTECTED] writes:
Property Id=NOEXESTART Admin=no Hidden
Hi,
Thank you for your hints, but this just doesn't work correctly.
I do not need to create custom errors, if Condition statements do the same.
So the helpful thoughts are in the lower part of your mail.
That however does not work. If I set the UI_RAN property, the condition only
fails if
for setup in GUI and without GUI?
You've set suppress=yes, which means the event doesn't occur.
Rob
Mailinglist wrote:
Hi,
Thank you for your hints, but this just doesn't work correctly.
I do not need to create custom errors, if Condition statements do the
same. So the helpful thoughts
Hi Wix-users,
Solved the problem, easier than thought. To disable LaunchConditions in UI Mode
simply add the following:
InstallUISequence
LaunchConditions Suppress='yes'/
/InstallUISequence
Important, must be in InstallUISequence so that the LaunchConditions are run
if the msi is
Mailinglist wrote:
Hi Rob,
You've set suppress=yes, which means the event doesn't occur.
Last compile I tried the following:
InstallExecuteSequence
LaunchConditions Suppress='no'NOT (GUI=1)/LaunchConditions
/InstallExecuteSequence
And it did not work either, it fails with the specified
Hi,
more to do, more problems show up...
1. Setting property in merged module at runtime.
In the setup I use a merge module, where a custom action is triggered via a
property. This property shall be entered to the setup as a command line switch
like:
[code]
msiexec.exe /I setup.msi
Hi WiX-Users,
in our Setup we use a personalized GUI, that checks in its first dialog several
conditions and shows messages, if one condition fails. Most of this conditions
handle previously needed software, like MMC 3.0 and Powershell 1.0.
This just works fine for us, but if the install is
Hi,
actually I noticed, that one condition in my previous post is unlikely to work,
since it checks those servers with these properties:
Property Id=VERSIONFULLSQL Admin=yes
RegistrySearch Id=VERSIONFULLSQL_RegSearch Root=HKLM
Hi wix-users,
We need the ability to store a certificate CA to the root store of the local
machine, and a certificate to the TrustedPublishers store of the local
machine.
Those files are needed for our Powershell files, which are not loaded otherwise.
Until now, with WiX-3.0.3015.0 I only
Hi Johan,
How does this work around the technical reason for managed custom
actions not working that Rob Mensching blogged about recently?
Well, it works, though we have not testet calling managed custom actions for
different framework versions. We roll out our software, entirely written for
Hello WiX-users,
because we needed to use managed custom actions in our setup, I searched around
the net for a real solution to this.
I found two projects ([1],[2]), that followed quite good ideas, but both did
not work out of the box or only under special circumstances. So I combined them
34 matches
Mail list logo
