Hi,
Please excuse me if this has already been discussed before. I am trying to
implement a bootstrapper for multiple cultures. After searching around, I
found some help but with that, I am only able to build 2 separate MSIs for 2
cultures and I now have to build 2 separate bootstrapper exe packag
Hi,
Could you please update any idea on this?
Thanks in advance.
Regards,
Mohamed Yasir K
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Access-installation-progress-values-outside-Bootstrapper-application-tp7598824p7598839.html
Sent from t
No. You'd have to hack up the wix MSBuild targets *significantly* to get there.
Not at all designed to work that way.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: ronif [
You are correct: ProductSearch does have an UpgradeCode too, I am using wix
3.8 and the documentation of 3.8 doesn't make reference to the UpgradeCode.
I will try using 3.9.
I will also investigate (learn) what you mean by implementing code in the
ba (???) for the OnDetect handlers.
Thanks for y
I suspect that you might be able to create a MSBuild targets file that would
do that. The wix source tree uses MSBuild targets files (.proj) which
reference groups of projects. Each project still has a project file (.proj
or .wixproj), which is unique to the type of project being output (by
setti
Hi,
Is it possible to have only one project the contains both Burn related parts
(installing prerequisites,...) and regular MSI parts?
(i.e. uniting and ?)
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uniting-Burn-and-WiX-MSI-projects-tp759
I'm a little confused by the comment about ProductSearch, sorry.
- ProductSearch: requires a product code which I cannot use
The wix:ProductSearch for use in authoring an MSI takes
ProductSearch/@UpgradeCode as the input.
The util:ProductSearch for use in a bundle takes either a ProductCode or a
Hello Everyone,
I have two mutually exclusive products I need to write an installation for.
These two products are part of our daily builds so I cannot predict what the
Package and Product codes will be for the current and future releases.
I have done some research and have found a few alternativ
Thanks for the fantastic detailed clarification on this issue! I will endeavour
to use the melt approach outlined in Bob's post.
-Nick
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET i
[1D28:0570][2015-01-12T15:19:10]i101: Detected package: Application, state:
Obsolete, cached: None
[1D28:0570][2015-01-12T15:19:12]i201: Planned package: Application, state:
Obsolete, default requested: None, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, depe
I would also enable MSI extra debug logging and evaluate the msi logs,
typically in %temp%. My first guess, and it is only a guess (without
specific data from the log) is that on a x64 system, if the msi CA tried to
launch a 32 bit version of the api it would fail. But again this is only
one poss
You need to evaluate the verbose log (or past to a post relevant parts for
others to help). It is typically in your %temp% folder, with obvious name
based on your product name. There will be a log for the bootstrapper which
contains the 'plan' and for each msi, if launched.
--
View this messag
12 matches
Mail list logo