Do a search/replace on the generated components wix or use an xslt to
transform it into payloads if it's something you will need to do repeatedly,
in fact you can pass an xslt to heat to transform it for you.
-Original Message-
From: nianderneves [mailto:niander.ne...@gmail.com]
Sent: 25
What Jacob suggests works, we have been using it for several years, if the
certificate is in the original msi and it and the patch are signed by the
same certificate then you do not need to elevate to install.
It's fun when the certificate expires though as you need to use a hotfix to
deliver the
It also requires that the service is setup to allow non-elevated privileges
to stop it.
Event Viewer\Windows Logs\Application
Source: RestartManager
-Original Message-
From: Joel Budreau
Sent: Tuesday, June 25, 2013 6:22 PM
To: afor...@cmu.edu ; General discussion for Windows Instal
Hi,
I am a neophyte w/r/t wix. I created an installer from within VS2012, and so
far, so good. But no matter what I do, I cannot get a dialog to fire. I get
the "preparing to install" screen, then "configuring..." screen, and then the
installer finishes without any additional dialog.
All I
Hi,
I am a neophyte w/r/t wix. I created an installer from within VS2012, and so
far, so good. But no matter what I do, I cannot get a dialog to fire. I get
the "preparing to install" screen, then "configuring..." screen, and then the
installer finishes without any additional dialog.
All I
Thanks for your reply. How do I use the "set" command to get the size of the
block? I ran it in both pre-and post-build, but I don't know how to tell if
what I see is too big or not. What is too big?
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Wednesday, June 2
I figured this out, was simply the flags to misexec.
Thanks,
Carl
-Original Message-
From: Carl Buxbaum [mailto:cbuxb...@tradestonesoftware.com]
Sent: Wednesday, June 26, 2013 10:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Cannot get dialogs to fire
Hi,
I am a neop
More info. The installer runs correctly standalone, but when packaged in a CAB
from the web I get the behavior described below.
Thanks,
Carl
-Original Message-
From: Carl Buxbaum [mailto:cbuxb...@tradestonesoftware.com]
Sent: Wednesday, June 26, 2013 10:14 AM
To: wix-users@lists.sourc
I’m really stumped on a failure rollback scenario with multiple MSI’s bundled
in a WiX bootstrapper.
Consider the following WiX bundle chain:
a.msi creates a few files in C:\Program Files (x86)\a
b.msi creates a few files in C:\Program Files (x86)\b
[Step 1]: A computer has a co
How is the MajorUpgrade element scheduled in your MSI? By default it is
"afterInstallValidate", which does not bring back the old version if there
is a rollback. See the documentation at
http://wix.sourceforge.net/manual-wix3/wix_xsd_majorupgrade.htm.
--
View this message in context:
http://w
The A msi was successfully upgraded though. The issue is there are 2 installer
transactions that are run in sequence. The first works, the second fails.
It gets difficult to roll back the bundle, because it would need to reinstall
the previous bundle if the upgrade failed. What if the original
I'm still not grasping what's happening. Do I have this right?
* You have a dependency on .NET 4
* You used the WiX .NET extension in your Burn bootstrapper to install .NET
if it isn't already installed
* For the portion of the install (after .NET is installed) that applies to
your own software, y
Burn caches MSIs that are in the bundle in the Package Cache, so having the
original media, I wouldn't /think/ would be a problem. When one MSI in the
bootstrapper chain fails, all preceding MSIs should be rolled back.
--
View this message in context:
http://windows-installer-xml-wix-toolset.68
Burn "can" cache them, but if you set *Package/@Cache to 'no' it won't.
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: Wednesday, June 26, 2013 12:05 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bootstrapper multiple MSI’s don’t rollback to a
Hello
I've created a VS2012 project with WiX which produces an msi file. It has a
user interface and works as I'd like it to. Now I've been asked to create a
setup.exe so I added a Bootstrapper project and reference my msi file in the
bundle - see below
Recommended approach here is to use bundle to show GUI and have MSI behind the
scenes controlled with properties. But depending on the completity of your GUI
you may want to display its GUI. There is an attribute on the MsiPackage
element that allows you to do that.
Wes
-Original Message
That makes sense then. I wonder if adding the *-cultures:en-us* flag or
*-cultures:fr-fr* to the Linker tool settings in the bootstrapper's
properties would do the trick?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers
I have an ExePackage defined,
which can output a few different exit codes. What I would like to have
happen, is to prompt for restart at the end of the bootstrapper's chain
if a specific exit code was returned.
I'm using the standard WiX Toolset for everything so yes I'm using WiX Standard
Bootstrapper Application (WiXStdBA).
The original media is available and cached by default because my workaround is
to manually go into the Control Panel, Programs and Features and repair the
entire installed versio
In the context of the bootstrapper chain rollback event the individual MSI
MajorUpgrade Schedule element is irrelevant since this only comes into play
when rolling back 1 MSI. In my case a.msi has been upgraded successfully
therefore the old existing product is removed. Then when b.msi fails a.m
I have an ExePackage defined,
which can output a few different exit codes. What I would like to have
happen, is to prompt for restart at the end of the bootstrapper's chain
if a specific exit code was returned.
Thanks Wes. I've found that property. Any idea how I can stop the
bootstrapper displaying the license screen? I've tried using the
WixStandardBootstrapperApplication.Foundation but then I don't get a GUI at all.
Suzy
-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Two ways:
Set text to empty as mentioned here:
http://stackoverflow.com/questions/15441516/wix-wixstdbalicenseurl-doesnt-hide-license-when-custom-theme-used.
I never did this.
Or you can create a theme. Which allows you more flexibility in GUI.
E.g.:
http://www.dynagen.ca";
I don't know enough about Burn, so I don't know if it can do this but...
I think that what you want is both MSIs installed as single MSI transaction,
wrapped in MsiBeginTransaction/...EndTransaction etc. Then if b.msi fails
the entire (a + b) transaction rolls back, including the major upgrade of
That's great. Thank you for your help - much appreciated.
Suzy
-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: 26 June 2013 19:59
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating setup.exe from WiX msi file
Two ways:
We have a burn bundle of 3 msi payloads. 1 is compressed the other 2 are
external. All created with Wix 3.7.1224
The msi are all signed as they build and all install per machine
When installing to XP from a network share while logged on as an admin.
Burn fails if I sign the bundle (insignia and
I would check to see that the machines are up to date with Windows updates,
specifically looking for the root certificate updates.
-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Wednesday, June 26, 2013 3:15 PM
To: 'General discussion for Windows
That sounds reasonable. However, how do I do this? "Cultures to Build" is
disabled and I don't see any other spot to set this?
From: Nick Ramirez [via Windows Installer XML (WiX) toolset]
[mailto:ml-node+s687559n7586876...@n2.nabble.com]
Sent: Wednesday, June 26, 2013 11:56 AM
To: Mark Van Dyk
The MajorUpgrade schedule is important for the MSI that failed. If an MSI
will be rolled back, having the original MSI reinstalled is dependent on the
MajorUpgrade element. On the other hand, the first MSI, which installed
fully, will not roll back. At best, when the Chain fails, it will probably
j
Windows updates are current. Root certificates hadn't occurred to me. I see
future dates on most of the entries so I think they are current and a quick
visual compare with my Win 7 box has many of the same entries.
I can't update Certificates directly because of our AD Policies.
We are still
If you go to a failing box and right click on the signed exe, select
properties, click the Digital Signatures tab, click the Details button, does it
say the certificate is valid?
-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Wednesday, June 26,
I think a log file would be necessary:
https://support.firegiant.com/entries/24024218-Create-a-log-file-
On Wed, Jun 26, 2013 at 11:23 AM, Steve Merckel wrote:
> I have an ExePackage defined,
> which can output a few different exit codes. What I would like to have
> happen, is to prompt for re
Let's forget about the Windows Forms portion. I apologize for throwing that
into the mix and confusing things.
What I am about to say only applies if a .NET dependency is detected and the UI
is displayed for that.
* I have been able to customize the .NET installation GUI using a .thm
You are correct this is how it is currently working in WiX 3.7 and this is my
problem. The MSI that fails (b.msi) does rollback correctly, my issue is that
the installed files of a.msi are lost until I manually repair the previous
bootstrapper version from add/remove programs.
A RollbackBoundar
Actually, I think I may have spoken too soon. I believe the 0x80004005 error
means "access is denied". If it were the certificate that failed I would have
expected a 0x800b010a: Failed authenticode verification of payload.
Do you happen to have any Anti-Virus software on the XP machines? It ma
[1EBC:1AD4][2013-06-26T17:18:24]i001: Burn v3.7.1224.0, Windows v6.1 (Build
7601: Service Pack 1), path: C:\Code\_swankmptfs1\Media
Player\MAIN\Dmp.Setup.Bootstrapper\bin\Debug\Dmp.Setup.Bootstrapper.exe,
cmdline: ''
[1EBC:1AD4][2013-06-26T17:18:24]e000: Error 0x80070057: Failed to parse @Code
The same certificate is used to sign everything and it is valid. I checked the
permissions and they are OK. Then I emptied the package cache and re-ran the
bundle. This is our first install by a bundle to use the package cache on that
machine. I think McAfee is what I'll chase next. I like to
Sorry to confuse, The localization variables are just the ones defined in the
unmanaged bootstrapper that runs when a .NET 4.0 dependency exists (i.e.
.NET 4.0 is not present on the target system). I handle translations myself
in the Windows forms portion of the custom managed bootstrapper UI.
I
Thanks for your reply to my issue. This sounds like something internal to
WiX. Is this something that I should be doing? From my meek understanding
of WiX though, what you are positing sounds like it could be the source of
the problem unless I am missing something.
Sorry for the delay in replyi
In the bootstrapper project's Visual Studio properties, go to Tool Settings
and enter the command-line args into the Linker text box.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers-Duplicated-tp7586776p7586899.html
Se
Look for the answer by imagi on this page:
http://stackoverflow.com/questions/1064580/wix-3-0-throws-error-217-while-being-executed-by-continuous-integration
There was also a bug on Microsoft's Connect but I'm not seeing it right now.
> From: kmo...@profitstars.com
> To: wix-users@lists.source
I think that the different language WXL files need to be in different
subfolders named after LCIDs in burn's payload.
Blair
> Date: Wed, 26 Jun 2013 16:41:31 -0700
> From: nickra...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Burn - Localization Identifiers Dup
42 matches
Mail list logo
