Hi,
I've created a custom managed bootstrapper using Burn which executes an MSI
during the install phase. This MSI installs/configures a database.
During the UI phase I'm currently using this SQL statement to determine whether
I'm allowed to create a database:
SELECT COUNT(*) FROM
Hi,
I've created a custom managed bootstrapper using Burn which executes an MSI
during the install phase. This MSI installs/configures a database.
During the UI phase I'm currently using this SQL statement to determine whether
I'm allowed to create a database:
SELECT COUNT(*) FROM
, 2 Jul 2013 15:37:52 +
Subject: Re: [WiX-users] Condition on service permissions
Ok, an immediate custom action would do the trick.
Is there anything out-of-the-box that I missed? I'd really like to avoid
custom actions if I can...
Kind regards,
Henning Krause
-Original
Hi all,
I have a setup which installs three services:
ServiceA, ServiceB and ManagementService.
ServiceA and ServiceB are in different features but have a dependency on
ManagementService, which lives in its own feature.
SerivceA and ServiceB should be able to start/stop the ManagementService.
Ok, an immediate custom action would do the trick.
Is there anything out-of-the-box that I missed? I'd really like to avoid
custom actions if I can...
Kind regards,
Henning Krause
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Dienstag, 2. Juli 2013 17:28
. The process just
enumerates the features and writes them to stdout. This response is then
collected by the bootstrapper.
Kind regards,
Henning Krause
-Original Message-
From: Igor Paniushkin [mailto:ipaniush...@sdl.com]
Sent: Dienstag, 9. Oktober 2012 13:27
To: General discussion
.
The problem is, that I can't tell burn to restart the computer. The only way I
know is the Result property in the OnApplyComplete handler. But that method is
long gone...
Is there another way to tell burn to restart the computer? Or do I have to
implement that on my own?
Kind regards,
Henning
using the Managed API for IIS. However, it seems that even reading the current
IIS configuration required elevation. So it would seem the entire Bootstrapper
has to be elevated, which has some smell IMHO.
What is the best practice in this scenario?
Kind regards,
Henning Krause
Hi Rob,
You'd have to spin of a separate process that can elevate. We've talked about
adding somethig like this to Burn for IIS because they made a huge API blunder
and required read operations to be elevated. sigh/
But with an additional elevated process the use would have to go through the
Hi,
0x80070002 means file not found. Make sure you have your file references in the
bundle correct. You can also use Sysinternals ProcMon to see where the bundle
tries to locate your bootstrapper.
Kind regards,
Henning
-Original Message-
From: Adkins, Christopher
Seems to be a bug in PowerArchiver. I had the same issue and reverted to
Windows Explorer to extract the files...
Kind regards,
Henning
-Original Message-
From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
Sent: Mittwoch, 22. August 2012 06:39
To:
but a workaround would be to carry a 64-bit
executable in your BootstrapperApplication payloads and launch that on
64-bit Windows to launch IIS Manager. Essentially a 64-bit proxy.
On Fri, Aug 10, 2012 at 4:15 AM, Henning Krause
m...@henningkrause.euwrote:
I have created a managed bootstrapper
violation
On 09-Aug-12 09:02, Henning Krause wrote:
I have investigated the issue further and come to the conclusion that it
happens during an upgrade of an existing installation. It tries to do
something
to the existing pacakage and looks up the package in the current bundle
using its id. When
for this?
Kind regards,
Henning Krause
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
Installer XML toolset.
Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
I want to supply some extra information on this defect as requested but it
seems to have gone missing. Anyone know what has happened to it?
Neil
-Original Message-
From: Henning Krause
Hi,
I'm working with the latest WIX version (v3.6.3206.0).
Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005:
Access violation reading location 0x0018.
After downloading the symbols from Wixtoolset.org, Visual Studio pinpointed
the exception to
: [WiX-users] Burn: WixStdBA crashes wih Access violation
On 08-Aug-12 12:00, Henning Krause wrote:
Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005:
Access violation reading location 0x0018.
Please file a bug so it doesn't get lost in e-mail.
--
sig://boB
http
: WixStdBA crashes wih Access violation
Does this crash happen at the end of the install? My users have reported a
problem when upgrading today and I updated the build to 3.6.3206 yesterday
and wonder if this is the same issue.
Neil
-Original Message-
From: Henning Krause [mailto:m
Hi,
as part of my managed bundle, I may need to activate certain Windows Features.
Since I'm targeting Windows 2008 R2 or later, I can safely use the
Add-WindowsFeature and Get-WindowsFeature cmdlets.
The Add-WindowsFeature would be called from a custom action. However, I want to
display a
in a 64-bit process.
--
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
-Original Message-
From: Henning Krause [mailto:m...@henningkrause.eu
going to have to find a way to force the 64-bit powershell to
be
called or your context will be wrong.
--
John M. Cooper
-Original Message-
From: Henning Krause [mailto:m...@henningkrause.eu]
Sent: Wednesday, June 27, 2012 8:24 AM
To: General discussion for Windows Installer XML
of the
administrator. Now, should I put this stuff in a custom action in my setup?
Or should I do this right from the managed bootstrapper?
Are there any other options I have missed?
Kind regards,
Henning Krause
--
Live
Just working on a managed bootstrapper myself...
Using
Debugger.Break()
I can successfully attach Visual Studio to the bootstrapper application. No
problem stepping through the code from there.
Kind regards,
Henning
-Original Message-
From: Rob Mensching
Hi,
I've probably run into a bug with the latest WIX 3.6 build (see issue
https://sourceforge.net/tracker/?func=detailaid=3521939group_id=105970atid=642714)
on SourceForge.
Basically, I've an MSI which installs a file in a per-user scenario:
?xml version=1.0 encoding=UTF-8?
Wix
, Henning Krause
m...@henningkrause.euwrote:
Hi,
I've probably run into a bug with the latest WIX 3.6 build (see issue
https://sourceforge.net/tracker/?func=detailaid=3521939group_id=105970
atid=642714)
on SourceForge.
Basically, I've an MSI which installs a file in a per-user scenario
Hi,
I have a burn chainer which installs an MSI. If the MSI fails (error 1603),
I only get said error code in the burn log (msi failed with error
0x80070643). That's not very helpful because 1603 is kind of a standard
error message.
Is it possible to get a verbose MSI log from the package?
Can
Hi all,
I've created a bootstrapper using burn which works rather well.
One thing however: If I execute the bootstrapper multiple times, I always
get the Install sequence. The install phase will then run, but since all
chained products are already installed, the system is effectively not
I'm using WiX v3.6.2610.0
Test platform: Windows 2003 x86 en, latest service pack
I created a Burn Bootstrapper which installs one MSI as Per User. Depending
on the state of the target machine, some prereqs have to be installed
per-machine.
So I created this bootstrapper:
?xml
28 matches
Mail list logo
