Hello,
Is there any way to tell WIX that when uninstalling the program,
uninstall a file ONLY if it has not been modified after the
installation?
That could be very useful for backing up config files,
Thanks a lot.
If it's a payload in your BootstrapperApplicationRef, then it'll be
extracted to the same directory as the burn engine and your Managed BA
assembly, so you should be able to get the path from that.
Nicholas
On 4 June 2013 17:34, Carlos Hdz Taylor carlos...@live.com wrote:
Hello guys,
I am
Attached a sample log file four your reference.
Realized that the directory created in C:\ProgramData\package Cache which
holds the Execpackage gets deleted the moment I set Result.cancel to
trigger rollback.
On Mon, Jun 3, 2013 at 12:13 PM, wix user rooparu...@gmail.com wrote:
On comparing
Attached a sample log file four your reference.
Realized that the directory created in C:\ProgramData\package Cache which
holds the Execpackage gets deleted the moment I set Result.cancel to
trigger rollback.
But Im not able to figure out why.
On Mon, Jun 3, 2013 at 12:13 PM, wix user
Hi at all!
I have working in a WIX project that’s only install 3d data file library (not
.exe’s). I’d like, after install, add a new entry in user Library (in Windows 7
or above) like that.
Libraries
===
Documents
Music
Videos
Images
* My 3d files
The approach I am following is:
1) Install
Hi,
i have an ExePackage in which the exe uncompresses some files, then run an
installer and returns without waiting for this installer to finish.
Is there an option to set in wix, where it would monitor the child
processes created by the exe in the ExePackage and wait for them to finish
before
Hi all,
the doc says it is possible to have multiple RemotePayload tags under the
same ExePackage tag.
If this is real, which EXE is runned ? The 1st one ? All ?
Thks,
B.
--
How ServiceNow helps IT people transform IT
Hello,
We are trying to build an MSI that supports MultipleInstances and wrap it
with a custom Burn bootstrapper application.
Our MSIs install MultipleInstances successfully when we run them with
msiexec from the command line.
But running it through Burn doesn't do anything... the first instance
I don't think so. Other people here have created their own custom executable
that wraps the installer in weird cases like this. Your wrapper would have to
handle install, uninstall, and modify command line args.
-Original Message-
From: Benjamin Mayrargue [mailto:benja...@vapolia.fr]
+1
I'm imagining a sequence of CustomActions timed such that each one installs the
files (i.e. runs an EXE package, if I understand your case) in the order you
want, and you'd want to run the uninstallation versions of those CAs in reverse
order for uninstall.
Alain
-Original
Thanks Nicholas, and how can I get the path for that?
If I look at a Process Monitor capture, I can see that when I execute the EXE
installer the EULA file is copied to the following location:
C:\Users\carlos\AppData\Local\Temp\{e9b77076-6fdf-4281-a8c3-7efed6bf46b7}\.ba1\EULA.htm
But when
Actually burn wouldn't be able to do that anyways because it has to know if the
installer failed so it can rollback the changes. Unless the package is not
vital in which case you specify Vital=no. Burn expects an exitcode (exitcode
element) from exe to indicate success/failure. I never used
What I ended up doing was extracting the location of the Executing Assembly
which is the same location where the EULA is placed.
If you can think off a better way of doing it please let me know.
http://stackoverflow.com/questions/52797/how-do-i-get-the-path-of-the-assembly-the-code-is-in
Hello,
I know I need to schedule the REP early that is what I want to do, but
due to some bad decisions by my predecessor I was unable to do that because the
REP would fail because of the custom action. I have however managed to find a
fix and get my REP scheduled early. To fix this
Hi,
I am making my Installer to Install into specific folder location instead of
Programfiles using a Property INSTALLLOCATION. Ans I pass its value through
command line during Installation.
MSI (c) (18:98) [08:04:53:170]: PROPERTY CHANGE: Adding INSTALLLOCATION
property. Its value is
You would need to write your own ExePackage that ran the EXE that did the
relevant calling and waited around for child processes. If an error does
occur, you'll need to return a non-zero exit code as that's how Burn
determines whether a package succeeded or not.
If the exe you're currently
That's exactly what we do.
Nicholas
On 5 June 2013 14:42, Carlos Hdz Taylor carlos...@live.com wrote:
What I ended up doing was extracting the location of the Executing
Assembly which is the same location where the EULA is placed.
If you can think off a better way of doing it please let me
yes Registry Key still exist .How do I remove it while Uninstallation.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-Package-Installation-location-tp7585460p7586380.html
Sent from the wix-users mailing list archive at Nabble.com.
Properties are not persisted. You need to have authoring to do this.
Generally, there is a Registry component to save the information to the
registry, and a RegistrySearch to recover it. Rob even has a blog on persist
patterns although the URL escapes me at the moment.
--
John Merryweather
If you have uninstalled, the persisted property registry key should not be
there.
Check that the keys have been removed before installing your new version.
-Original Message-
From: chennam [mailto:chatrapathi.chen...@gmail.com]
Sent: 05 June 2013 15:30
To:
If you know basic information about the child process (such as a window
title), then after your setup launches the exe package, and the package
returns successfully, launch a tool which calls FindProcess (or equivalent)
and get the PID, and then wait on that PID until the child process
terminates,
I don't think Burn supports instance transforms today.
Ref:
http://robmensching.com/blog/posts/2012/8/21/enter-wix-v3.7-toolset
http://comments.gmane.org/gmane.comp.windows.devel.wix.user/59015
Is there a reason you are using instance transforms instead of multiple MSI's?
I started with
Nevertheless, that immediate custom action is incorrect. I'll just repeat
that immediate custom actions cannot run installed files because no files
have yet been installed! This is a logical error in your install, and that
custom action action is working only because sometimes the installutil.exe
We have a ComPlusApplication which has an Identity and Password. The values
for these are logged in plain test in the msi log file, not encrypted. Am I
missing something on the ComPlusApplication which allows for hiding these
values? For the Username and Password properties that are entered,
Phil,
I see what you are saying. Thank you I will definitely fix that
issue in this current installer so that this problem doesn't happen again. The
only reason that I had to ignore the error is that this was occurring in the
previous versions installer and was preventing me
This has come up before quite recently(May 2013) in a DTF CA with a
ConnectionString.
Custom action code can interface with the MSI log to create entries there,
and because they just log a string they see they don't know whether the
content is private or not, and they do not participate in the
What I mean: the application is based on MSYS and when a new user starts the
unix shell, he needs write access to folders like /home, ... . And /home is
contained inside the Programfiles\aplications folder.
No it's not. On Windows the equivalent of Unix home directory would be the
location
Ah yes, Neil and Phil are quite right. I was using an older version of
Runtime.wxi. I've now updated it to what's below, and it seems to be setting
the Properties correctly. However, when attempting to upgrade, at the Validate
Install step, I *sometimes* get a message saying something like, The
Greetings to all,
I am having issues installing wix 3.6 and 3.7 on windows server 2008 sp2.
I have attached the log file created by the installer
Mustapha D. Kone
MCTS
NoWay is MyWay
NoLimit is MyLimit
Only thing I Know is learning
The log got stripped off. I've installed Wix 3.6 on quite a few Server 2008 R2
boxes (all but two of my build servers, developer boxes, and one of my two
boxes--all Server 2008 R2).
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS
Thanks for the prompt reply,
here is the errors found in the log file:
[12BC:12A4][2013-06-02T09:51:33]e000: Error 0x80004005: Failed to extract all
files from container.
[12BC:0424][2013-06-02T09:51:33]e000: Error 0x80004005: Faild to begin and wait
for operation.
Short Version: I can't uninstall wix toolset version 3.7 from Windows
Server 2012.
The log file says:
[0AD8:08B4][2013-06-05T12:08:01]i001: Burn v3.7.1224.0, Windows v6.2 (Build
9200: Service Pack 0), path: C:\ProgramData\Package
Cache\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\WiX37.exe, cmdline:
Are you connected to the internet from this location? Wix 3.6/3.7 use Burn
bootstrappers with download a lot of the installable components. If you have
no inet, nothing is going to get downloaded and the install will fail.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry
Sure am.
internet connection is not an issue
Mustapha D. Kone
MCTS
NoWay is MyWay
NoLimit is MyLimit
Only thing I Know is learning
From: John Cooper jocoo...@jackhenry.com
To: Mustapha Kone mustaph...@yahoo.com; General discussion for Windows
Hello,Is there a silent or unattend option to install the Wix toolset . We are
trying to install all necessary tools for our devs without any user
intervention. Thanks-Vinay
--
How
Hi,
Wix Toolset uses Burn to install. The normal Parameters for burn should work.
See Robs answer of this post
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-Burn-driven-installer-in-quiet-mode-command-line-parameters-td5913001.html
Am 05.06.2013 um 23:00 schrieb Vinay
36 matches
Mail list logo
