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 fn_my_permis
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 fn_my_permis
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
>
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 2
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.
. 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: Gener
.
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,
He
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.
But with an additional elevated process the use would have to go through the
el
l IIS
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 K
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 [mailto:christophe
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: wix-users@lists.sourceforge
I haven't played with this much 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
> wrote:
>
g has worked so far.
Has anybody a solution 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
shes wih Access 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 pa
To: wix-users@lists.sourceforge.net
> > Subject: Re: [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:
> >
WiX-users] Burn: 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
>
> -----Origi
rs@lists.sourceforge.net
> Subject: Re: [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.
> Pl
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 WixStandardBootstrapperApp
and you get the 32-bit one by default.
> You're probably 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...@henningkrau
> need to be using CAQuietExec64 to execute 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.jackhen
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 lis
lf 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
--
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 [mailto:r...@robmensching.
detected
> correctly.
> On Fri, Apr 27, 2012 at 2:31 AM, Henning Krause
> wrote:
>
> > Hi,
> >
> > I've probably run into a bug with the latest WIX 3.6 build (see issue
> >
> https://sourceforge.net/tracker/?func=detail&aid=3521939&group_id=105970
&
Hi,
I've probably run into a bug with the latest WIX 3.6 build (see issue
https://sourceforge.net/tracker/?func=detail&aid=3521939&group_id=105970&atid=642714)
on SourceForge.
Basically, I've an MSI which installs a file in a per-user scenario:
http://schemas.microsoft.com/wix/2006/wi";>
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
change
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:
http://s
28 matches
Mail list logo
