/@DisableRollback=yes, but it works correctly (ARP entry does not get
removed on setup fail) when Chain/@DisableRollback is omitted.
-Original Message-
From: Dan Puza [mailto:dp...@ultra-scan.com]
Sent: Wednesday, August 10, 2011 7:51 PM
To: WiX-users
Subject: Re: [WiX-users] Burn uninstall fails
by things
that could be distractions because there are a lot of bugs to fix yet...
smile/
On Fri, Aug 12, 2011 at 6:47 AM, Dan Puza dp...@ultra-scan.com wrote:
Obviously it's wrong. Can you offer any better viable workarounds
using more appropriate approaches, at the moment, until the bug gets
Does this make sense?
The first package in the bundle that attempts to uninstall returns an error
code (Package Vital=yes).
Processing stops and Setup Failed, as I would expect.
However the ARP entry for the bundle gets removed. I would expect that to
remain intact.
Is that indicated by the
.
It is an ExePackage.
-Original Message-
From: Dan Puza [mailto:dp...@ultra-scan.com]
Sent: Wednesday, August 10, 2011 6:45 PM
To: WiX-users
Subject: [WiX-users] Burn uninstall fails - bundle is removed from ARP
Does this make sense?
The first package in the bundle that attempts
I discovered that when Chain DisableRollback=yes, the ARP entry gets removed.
When Chain DisableRollback is omitted, the ARP entry remains intact as expected.
However, for other reasons, I don't want the rollback to happen...
From: Dan Puza
Sent: Wednesday, August 10, 2011 6:45 PM
To: WiX-users
Heh... for now as a workaround I am having the ExePackage kill the parent
process (the bootstrapper) when the user cancels it... in order to keep the ARP
entry... at least it works... :-/
-Original Message-
From: Dan Puza
Sent: Wednesday, August 10, 2011 6:58 PM
To: WiX-users
Subject
I am having trouble with Burn with certain of my per-user MSIs. The log shows
they are Absent, when they are really Present. Since for some reason it thinks
they are Absent, they don't get uninstalled, causing all kinds of problems.
I am installing and uninstalling as the same user.
Another
Hmmm... it appears that the one that didn't work, didn't explicitly have:
Package InstallScope=perUser
And when I add that, it seems to work properly.
-Original Message-
From: Dan Puza [mailto:dp...@ultra-scan.com]
Sent: Monday, August 08, 2011 9:19 AM
To: WiX-users
Subject: [WiX
-users] Burn doesn't detect (and therefore doesn't uninstall)
certain per-user MSIs
Ahh, that's interesting. Can you add that information to the bug that is open
on this issue?
On Mon, Aug 8, 2011 at 6:46 AM, Dan Puza dp...@ultra-scan.com wrote:
Hmmm... it appears that the one that didn't work
Would you say that this is a WiX bug? Can you think of any workarounds?
I've tried disabling CRL checking machine wide as described here, with no
success:
http://www.page-house.com/blog/2009/04/how-to-disable-crl-checking.html
I am not really knowledgeable about dealing with certificates in
3.6.1908.0
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, July 19, 2011 7:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Caching payload, sudden terrible performance?
What version of Burn?
On Tue, Jul 19,
To follow up, I just tried the same installer with an internet connection
present on XP, and the caching payloads took 12 seconds rather than 8 minutes.
-Original Message-
From: Dan Puza [mailto:dp...@ultra-scan.com]
Sent: Wednesday, July 20, 2011 9:28 AM
To: General discussion
and ARP
Why do you want to do this?
On Mon, Jul 18, 2011 at 9:38 PM, Bob Arnson b...@joyofsetup.com wrote:
On 18-Jul-11 19:12, Dan Puza wrote:
Is there a way to set the title of the bootstrapper without creating
an
Add Remove Programs entry for the bootstrapper?
No, at least right now
Should there be any reason for the much slower times between these two log
files for caching payloads?
For example,
Total time caching payloads: 8 minutes (slower) vs. 21 seconds (normal)
Caching 2KB .REG file: 1 minute 18 seconds (10:24:32 - 10:25:50)
Caching 1MB EXE file: 1 minute (10:25:50 -
I'm not sure what to look for in Process Explorer. CPU is basically 0%. If I
look at the Threads for Setup.exe (my bootstrapper), I see slow churning
activity for cryptnet.dll!I_CryptNetIsConnected and
CRYPT32.dll!I_CryptRegisterSmartCardStore. Green/red, loaded/unloaded, over
and over
Is there a way to set the title of the bootstrapper without creating an Add
Remove Programs entry for the bootstrapper?
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property
I'm not sure if this is a bug or not:
Out of all my packages, the biggest one by far is SQL Server. However, the
progress bar seems(?) to jump a large amount compared to the others when it
STARTS processing SQL Server rather than AFTER it completes and moves on to the
next. Has anyone else
Managed BootstrapperApplication/
http://wix.sourceforge.net/manual-wix3/authoring_bundle_application.htm
Meaning, you write a custom BootstrapperApplication using .NET (managed);
rather than using a standard one like
WixStandardBootstrapperApplication.RtfLicense (native, non-managed) or
Is it Win7 64 bit? If so, are you sure the correct registry is being
checked/written to (32-bit vs. 64-bit)?
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Tuesday, July 05, 2011 6:57 AM
To: General discussion for Windows Installer XML toolset.
Subject:
What kind of code are you trying to run? You can definitely run an ExePackage
(EXE file) at any point before, after, between installing any of your 3 MSI
files, without writing a complete BA. It's true you cannot run the UI inside
the MSI though.
However, and this is an ugly hack, but I have
?
--
Message: 4
Date: Wed, 29 Jun 2011 21:54:47 +
From: Dan Puza dp...@ultra-scan.com
Subject: Re: [WiX-users] Bootstrapping .NET Framework 4.0
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Message-ID
I've attempted to fix a bug mentioned by Rob about ExitCode in Burn (actually
candle) as it's pretty urgent for me to have that working for my project. I
thought I may be able to just copy over the modified candle.exe and wix.dll
into my Program Files (x86)\Windows Installer XML v3.6
-dDevEnvDir=C:\Program Files (x86)\Microsoft Visual
Studio 10.0\Common7\IDE\\ argument for? Will that Program Files reference
contribute to my PublicKey problems?
I have also been replacing wix.xsd in Visual Studio 10.0\Xml\Schemas with my
modified one.
-Original Message-
From: Dan Puza
\wixext
BalExtension\balutil
BalExtension\wixstdba
BalExtension\wixlib
BalExtension\wixext
-Original Message-
From: Dan Puza [mailto:dp...@ultra-scan.com]
Sent: Thursday, June 30, 2011 9:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Building
.
On Tue, Jun 28, 2011 at 2:45 PM, Dan Puza dp...@ultra-scan.com wrote:
Here is the situation:
I am creating a Burn bootstrapper to install my app (an MSI) and its
prerequisites. One of the prereqs is SQL Server 2008. One of SQL
Server's prereqs is Windows Installer 4.5.
Unsurprisingly
There's a section within the WiX 3.x manual from the WiX home page.
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm
-Original Message-
From: Dane Anderson (Wicresoft) [mailto:v-dan...@microsoft.com]
Sent: Wednesday, June 29, 2011 1:03 PM
To:
That depends on the value of the ComponentsLocation attribute of the
GenerateBootstrapper Task in your wixproj file, as well as the CopyComponents
attribute.
See: http://msdn.microsoft.com/en-us/library/ms164294.aspx
For example, if ComponentsLocation=Relative, and CopyComponents=true, then
Here is the situation:
I am creating a Burn bootstrapper to install my app (an MSI) and its
prerequisites. One of the prereqs is SQL Server 2008. One of SQL Server's
prereqs is Windows Installer 4.5.
Unsurprisingly, the WI4.5 installer exit code is 0xbc2 REBOOT REQUIRED. Can I
manage
Is there a community location where standard package definitions are publicly
available in one common repository? If not, that would seem like a good idea,
so that each of us individually are not all reinventing the wheel.
For example, I just made a separate post asking about problems I'm
Any tips for debugging / troubleshooting Error 0x80070002: Failed to install
MSI package in the Burn log?
The MSI installs fine on its own, but the bootstrapper fails on the MSI with
that error message. There are no other messages indicating why it might have
failed. There is the following
Is it possible to instruct Burn not to verify the signature of an ExePackage?
The EXE file is published by a third party, and can't be modified. Is it
really just not possible to use it in my bootstrapper since there is a problem
with the signature?
I am very new to Burn, so it could be that
I got around this for now by removing the certificate, as described here:
http://www.curlybrace.com/words/2008/09/12/stripping-an-authenticode-signature/
From: Dan Puza
Sent: Thursday, June 16, 2011 4:04 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Burn - Error 0x80096010: Failed
32 matches
Mail list logo
