I am getting Error loading prerequisite bootstrapper application because
managed host could not be loaded in the logs of my custom bootstrapper.
Originally I was using burn 3.9.2, and receiving error code 0x80004001. On
the advice of this thread (http://tinyurl.com/pt9ym65) I tried upgrading to
How can I provide functionality for feature-level selection in my custom
bootstrapper created by burn? This link (
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-create-a-feature-tree-with-burn-td7579948.html)
seems to suggest I can do so by examining the
If the Modified Date of the file is not the same as the Created Date, then
Windows Installer will NOT overwrite the file in a Repair situation, as it
thinks the user has modifications to the file that it needs to respect, so this
is the correct behavior. As for the second issue, I am not sure.
All,
Is there any way to use WPF/C# to make the GUI for standard msi dialogs? I
know I can do a Bootstrapper to do this, but, I was hoping to avoid that
overhead and just deliver an .msi with GUI designed with WPF.
Thanks in advance,
Brian
Marco,
What you have done sounds okay.
We use a vbscript to call heat for ANYCPU targets. What it does is extract
the 32 bit information into one wxs file, then copies that file for the 64 bit
msi, stripping out the common registration information and the file delivery
information,
We have a ComPlusApplication which has an Identity and Password. The values
for these are logged in plain test in the msi log file, not encrypted. Am I
missing something on the ComPlusApplication which allows for hiding these
values? For the Username and Password properties that are entered,
Hello all,
Just thought I would post this in case anyone else might have the same
problem. Our installer consists of a 32 bit install, which delivers most
files, including some COM visible .Net assemblies. We also have a 64 bit
installer which, for now, delivers some 64 bit
I agree. But, without a built in way of doing this, and with management
expecting what previously worked with Wise to work with Wix, it iwa the best I
could come up with.
From: Rob Mensching r...@robmensching.com
To: General discussion for Windows Installer
I have not tried the first, so I do not know if it will work that way or not,
but, I perfer the second way. That way the BA always passes the value to the
msi, then it is up to the msi to determine what to do with the value or what to
do if it is blank.
In your CS Code, you call
MyBootstrapperApplication.Engine.StringVariables[my_wixvariable] = VALUE;
From: victorwhiskey victorhwhis...@yahoo.com
To: wix-users@lists.sourceforge.net
Sent: Friday, November 16, 2012 11:54 AM
Subject: Re: [WiX-users] Is
Yes. RTM is 10.00.35.0002, HF1 is 10.00.35.0003, and HF2 is 10.00.35.0004.
The versions are so close together because we are testing, before our release.
I am rerunning the testing rolling the revision number (i.e. 10.00.35.0002,
10.00.36.0003, 10.00.37.0004). I will post the results.
Okay, done. https://sourceforge.net/p/wix/bugs/3116/ LaunchAction.Modify on
Present package does not call PlanMsiFeature
From: Bob Arnson b...@joyofsetup.com
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 9, 2012 10:00 PM
Subject: Re:
I am trying, in my Managed Bootstrap Application, detect that my bundle is
already installed and that a few optional features are installed as well. I
wrote the code below, but I never get into the PlantMsiFeature code. I have
set the EnableFeatureSelection on my MsiPackage. Basically, the
If you have an msi which is always installed, you could check the version of it
in the DetectRelatedMsiPackage callback. You have access to both the major and
minor version in the event argument.
From: Frauenhoffer, Sabine
Hi all,
I am wondering if anyone else has had an issue trying to build a Managed
Bootstrap Application with the Target as .NET 4. Compiled with Target as 3.5,
everything worked fine, then, for some company-wide WPF GUI enhancements, we
went to .NET 4.0. After adding System.XAML and
Hello all,
As the subject indicates, we are trying to use heat to extract registration
information from 64 bit dlls. I have read most of the posts related to this
and know that heat is not built 64 bit, but, we have built the source 64 bit
and still cannot get things to work. It appears to
that if we are running on
64-bit, just always ignore the ignored string, but that would prevent
distinguishing between no command line argument and the '/?' argument.
Brian
From: Brian C briancoving...@yahoo.com
To: Rob Mensching r...@robmensching.com; General
) always have the
ignored argument when double-clicking the bootstrap executable. Any ideas?
I am running with 3.6.3025.
Thanks,
Brian
From: Rob Mensching r...@robmensching.com
To: Brian C briancoving...@yahoo.com; General discussion for Windows
Installer XML
Hello,
I have a managed bootstrap application, C# XAML mimicking the
WixBA example, but I would like to drive it with command line arguments. I
have tried adding a void Main(string[] args) to the BA class, but that does not
get hit. I tried overloading the Run() the same way,
I am getting a new light error while compiling my bootstrapper application:
light.exe(0,0): error LGHT0001: Arithmetic operation resulted in an overflow.
Doesn't jump to any code lines inside of Visual Studio, so I do not think it is
anything in the code.
Any ideas?
Thanks in advance,
PM
Subject: Re: [WiX-users] Upgrade from 2803 to 2908 new light error
On 03-Jun-12 10:52, Brian C wrote:
I am getting a new light error while compiling my bootstrapper application:
light.exe(0,0): error LGHT0001: Arithmetic operation resulted in an overflow.
Grab the latest build: A recent fix
] Upgrade from 2803 to 2908 new light error
On 03-Jun-12 14:27, Brian C wrote:
Still fails on 2928 build. We are combining one msi with embedded cab files
and one msi with external cab files, all totaling 1.78 GB.
Sorry, I forgot that fix missed the RC build. It will be in the next build.
--
sig
From: Brian C briancoving...@yahoo.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Friday, May 25, 2012 11:46 PM
Subject: Re: [WiX-users] harvesting COM information using heat.exe results in
HEAT5150
Heat does
Heat does not extract for 64-bit dlls. We have had to write a script to
convert the 32 bit extraction into 64 bit.
From: Michael Scheepers mscheep...@tool-links.de
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
All,
I have what appears to be a simple chained install using burn, where I would
like to do a RegistrySearch to read a key created by the first msi, and use
that to install the second msi to a subfolder of that location. The first
S3DInstallation.msi has its’ own GUI which is run and
25 matches
Mail list logo