/@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 unins
focus on and I admittedly get a bit bent by things
that could be distractions because there are a lot of bugs to fix yet...
On Fri, Aug 12, 2011 at 6:47 AM, Dan Puza wrote:
> Obviously it's wrong. Can you offer any better viable workarounds
> using more appropriate approaches,
x27;t want to investigate any of them.
Anyway, this sounds like bug:
http://sourceforge.net/tracker/?func=detail&aid=3367340&group_id=105970&atid=642714
On Wed, Aug 10, 2011 at 5:48 PM, Dan Puza wrote:
> Heh... for now as a workaround I am having the ExePackage kill the
> pare
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 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 P
le to change the code returned from this package.
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 firs
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 t
ct: Re: [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 wrote:
> Hmmm... it appears that the one that
Hmmm... it appears that the one that didn't work, didn't explicitly have:
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
I am having trouble with Burn with certai
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 p
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 t
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 for
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, 20
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 again
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 ->
e and ARP
Why do you want to do this?
On Mon, Jul 18, 2011 at 9:38 PM, Bob Arnson 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 le
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 t
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 no
Managed
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
writing a native, non-manage
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
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: Re
b
UtilExtension\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-user
the candle.exe -d"DevEnvDir=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.
-Origin
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 directory.
download the pre-requisite files right?
--
Message: 4
Date: Wed, 29 Jun 2011 21:54:47 +
From: Dan Puza
Subject: Re: [WiX-users] Bootstrapping .NET Framework 4.0
To: General discussion for Windows Installer XML toolset.
Message-ID:
Content-Type: text
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
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: wix-users@lists.sourceforge
be installed and everything is good.
On Tue, Jun 28, 2011 at 2:45 PM, Dan Puza 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 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 hav
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 reboot
.iesve.com
**Design, Simulate + Innovate with the ** Integrated
Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20
0SP Email Disclaimer
-Original Message-
From: Dan Puza [mail
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
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 0x800960
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
34 matches
Mail list logo
