Hello all,
We have a config file that is installed which can be customized post
installation (not sensitive data). How can we save the config file during
uninstall so that customizations can be merged into the new install.
I was thinking along the following:
A. During uninstall copy the
Hello,
I think I have broken my WiX installation and have not been able to recover
from it.
I am using WiX 3.7 from command prompt on a 64-bit Windows 7 laptop.
When initially working on the tutorial for WiX
(http://wix.tramontana.co.hu/tutorial/user-interface/ui-wizardry), I was able
to
The pattern I follow is to:
1) have a custom action read XPaths from a table and save what it finds in the
existing file into properties;
2) re-write the XML file on install/upgrade with the values in those properties;
It is certainly possible to do a source control like merge, but your custom
I always tell developers to create 2 (or possibly more) XML files. One
that is owned by the installer and one that is owned by the application /
user. The installer will 100% own the file that it installs and there is
no expectation that the installer won't overwrite when it needs to.
Use Programs and Features to Uninstall Wix, then move your project out
of your Dev directory. Second, Delete your Dev Directory, then
redownload Wix37.exe and Wix37-sources.zip. Unzip the sources back
into your Dev Directory. After this open your Gui source Files in
your project, and
I'm sorry if I was not clear. I have not duplicated anything from the
sources. I am compiling and liking the tutorial from the website in the
original post. The .wxs file is below:
The compile command:
candle.exe SampleWixUI.wxs
The link command:
light.exe -ext WiXUIExtension -out WixUI.msi
You can display the same progress in your BA that you could with a basic UI.
Are you using WixStdBA or your own BA? If you are using WixStdBA you simply
need to add
Text Name=ExecuteProgressActionDataText X=11 Y=163 Width=-11
Height=17 FontId=3 DisablePrefix=yes/
To your progress
Thank you. I did take your advice and look at going through things one by
one. I actually retreated to downloading a clean version of the sample and
compared the files and found an error my working version of
SampleFirstUI.wxs file.
The line:
UIRef Id='WixUI_InstallDir'/
was causing
I found a WiXWPF Bootstrapper project on Codeplex
(https://wixwpf.codeplex.com/) that hasn't been updated for WiX 3.8 yet. I
downloaded the source and tweaked all the references I could and go it to
compile and install. I was able to get their project templates to show up
in VS2010/2012 but
Yes, the easiest way to Fix that:
1. Copy original UI File from WixSources into your Dev Sources.
2. Rename Your Copy, as in WixUI_IntallDir-project name
3. Change the UI Reference you noted below to point to the file from step 2.
Quoting Kelli Hendrickson ke...@wamit.com:
Thank you. I did
1. Have the user copy it to a location. Put said location somewhere
in the Uninstall UI. There is no CopyFiles Action during uninstall
2.In your installer, write a conditioncheck etc that checks for the
location you gave in 1.
3. Check for File in Location.
4. If file exist, replace default
The general rule is that if the process is already running it won't pick up
the new environment strings, which is why things like services and command
prompts won't pick up the new values. Sometimes the definition of new
process isn't that obvious. If you have a running command prompt from
which
I use slightly modified WixStdBA. I'll try to use ExecuteProgressActionDataText.
But anyway, it is good idea be able to set any possible UILevel for covering
all UI variants for 3rd party MSIs.
Sometime that really necessary.
-Original Message-
From: Hoover, Jacob
I agree. I feel dirty whenever someone asks me to modify the path. It's
usually the Java guy s but then the MS PowerShell guys come by and they
only give you two options (that I know of) to register a module. 1)
Update the PSModulePath and 2) Install in the root PowerShell Modules path
Hi,
I'd like to enable our partners to simply add a few files to our installer
package (an msi) before they deliver it to their customers (e.g., to add
third-party plugins, certificates, and various other configuration files). So
far, I've been prototyping a simple tool based on DTF to add
2013/11/1 Bas Graaf bas.gr...@microsoft.com:
Hi,
I'd like to enable our partners to simply add a few files to our installer
package (an msi) before they deliver it to their customers (e.g., to add
third-party plugins, certificates, and various other configuration files).
So far, I've
Hi all,
I have seen this in my MSI log files but not really sure what this means:
MSI (s) (D8:28) [17:59:01:448]: Doing action: SchedSecureObjectsRollback
Action 17:59:01: SchedSecureObjectsRollback.
Action start 17:59:01: SchedSecureObjectsRollback.
MSI (s) (D8:68) [17:59:01:525]: Invoking
Yes, we considered giving them our source also. However, we'd like to keep it
as simple as possible (for them). Typically, they would not know anything about
WiX or Windows Installer internals and our WiX source is quite complicated.
Although the wixlib suggestion would at least not expose them
2013/10/26 Tunney, Stephen stephen.tun...@nuance.com:
2013/10/26 Nicolás Alvarez [nicolas.alva...@gmail.com]:
2013/10/26 Tunney, Stephen stephen.tun...@nuance.com:
I get errors now in my pyro call stating that the PatchBaseline I've
selected does not have any changes, but I know for a
fact
Pretty standard as I see it in all of my logs. Permission/ACL's don't really
rollback. Noise.
--
John Merryweather Cooper
Build Install Engineer -- ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
Thanks John phew :)
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: November-01-13 6:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SchedSecureObjectsRollback: Failed to store ACL
rollback information with error 0x80070003 -
I did something like this for one of my customers. He had value added
resellers that would inject custom files and metadata / rebranding it. The end
user sysadmins would then make additional tweaks before distributing across the
enterprise. Each layer could then seal certain attributes so
22 matches
Mail list logo
