Hi,
I'm using util:XmlFile to change a connection string in a file and a
Password is involved which i would like to hide or not log.
util:XmlFile Id=XML_File.exe.config
File=[Dir_File]File.exe.config
ElementPath=//configuration/connectionStrings/add[\[]@name='ABC'[\]]
Action=setValue
You call Detect, then Plan, and then Apply on the engine. How you intersperse
those calls with what you show when in your UI is ultimately up to you.
Date: Tue, 26 Nov 2013 11:55:54 +0530
From: dileep.sanamp...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [WIX]: How to
The CustomAction tag inside of the UtilExtension for the deferred portion of
the XmlFile custom action doesn't have the HideTarget attribute set. I thought
there was an issue opened on that at some point, but I don't recall right now.
You could update the MSI post-binding to set that bit in
From what I can see poking around the * should not have been dropped...
Date: Mon, 25 Nov 2013 13:57:26 -0500
From: yellowjacketl...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 3.7: iis:WebAddress IP=* works,but generates
different .config entries...
I
Classification: Public
I agree :)
I enjoy making minor changes to the Extended BA DLL and look forward playing
with the 3.8 BA :)
Steve
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: November-25-13 6:15 PM
To: General discussion about the WiX toolset.
I do not know too much about this, but the code that was posted has the * for
'site 2' but not for 'site 1'. Is that a typo in the code?
bindings
binding protocol=http bindingInformation=:80:site1.localhost /
/bindings
--
View this message in context:
Sorry, please ignore my last post.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-7-iis-WebAddress-IP-works-but-generates-different-config-entries-tp7590938p7590968.html
Sent from the wix-users mailing list archive at Nabble.com.
I use a Wix burn bundle to install a few MSI packages and during the
initial install all registry entries get created fine.
The issue is when I do an upgrade, it seems that not all of my
registries are being created even though the log file lists that it is.
Anybody know whats going on?
I use a Wix burn bundle to install a few MSI packages and during the
initial install all registry entries get created fine.
The issue is when I do an upgrade, it seems that not all of my
registries are being created even though the log file lists that it is.
Anybody know whats going on?
I want to use a temporary file to transfer data between my immediate custom
action and my deferred custom action (Impersonate=no). I use the method
“Path.GetTempFileName()” to create a unique file in the immediate CA. The file
will be created but the deferred CA cannot see this file.
Where I
All of my websites use '*'; however, none of them end up with '*' in their
binding. Though they do appear to be working.
After the install, if you open the site in ISM and then click on
'bindings', the '*' is missing. If you then click 'Edit', followed by
'OK', ISM will add the '*'. Which is
I wrote a immediate custom action and a deferred custom action.
The immediate custom action will be executed after InstallFiles and the
deferred custom action is executed with the command “session.doAction” in the
immediate custom action.
When in the sequence the deferred custom action is
Thanks for the suggestions. We had an existing custom action that set the
LogEventOnRecycle, I left it in place. I was hoping I could remove it and
make use a native WiX capability.
On Fri, Nov 22, 2013 at 5:20 PM, John Cooper jocoo...@jackhenry.com wrote:
And for all that appcmd.exe, to
If the users are different so is the temp location. The immediate CA gets
the user's temp path, the system account (no impersonation) uses the
system's temp path. As long as you create the file where both have access,
perhaps you could put the actual path to it in the registry.
Phil Wilson
On
Hi Dima,
can you please explain me where you place your temporary file?
I want to transfer data between my immediate custom action and my deferred
custaom action (Impersonate=no).
Regards,
Jens
--
View this message in context:
Here's another approach to consider:
http://blog.iswix.com/2011/10/beam-me-up-using-json-to-serialize.html
From: Jens Teutenberg jens.teutenb...@t-online.de
Sent: Tuesday, November 26, 2013 12:54 PM
To: wix-users@lists.sourceforge.net
Subject:
Do you need to include this MajorUpgrade
Schedule=afterInstallValidate DowngradeErrorMessage=A newer version
of this application is already installed. AllowDowngrades=no/ in
each MSI if you wrap all of the MSI's in a burn bundle?
Thank you,
Michael Ogilvie
Between InstallInitialize and InstallFinalize all deferred actions are written
into the installation script (along with the properties named after them at the
same moment in time). When any of the InstallExecute, InstallExecuteAgain, and
InstallFinalize actions run, they run the script from
You could also put the actual path into the CustomActionData. Realize that
anything that the nonelevated immediate action has write access to isn't secure
and could be tampered with before the elevated deferred access can access it.
-Blair
Date: Tue, 26 Nov 2013 11:06:00 -0800
From:
That is certainly a reasonably good way to transfer structured data. I believe
the concern was one of space, but if you compressed the json (which already has
a low overhead and compresses well with algorithms that are good with text) you
may fit the entire table into the CustomActionData
20 matches
Mail list logo
