Easiest way into Burn, is to use VS 2010 and open the .sln file. It's like
the only .sln file that opens correctly in all of the WiX toolset.
Burn is new and since we are planning to migrate the WiX build to a pure
MSBuild solution in the future, we wanted to see how far we could go with
Burn. We
For a few years I've maintained a behemoth of an installation written in
Installshield that has hit a point that it's really just too much to maintain.
I had some thoughts of using a front end with multiple MSIs on the back end for
various pieces, and have come to find out that burn seems to fi
I missed this response earlier. Based on my reading of the below, it
definitely sounds like you want a Component/Condition.
Note: insulting (e.g. "Even a new CS grad knows that...") the people that
volunteer to help you by providing free tools and advice isn't terribly
constructive. It is particul
How about using Feature/Condition to disable the appropriate Features? Or if
you need really fine grained control, maybe Component/Condition.
Maybe it just requires looking at the problem from a different point of
view. Trying to be very procedural tends to be very frustrating in a
declarative sys
You can actually use a command-line parameter today... it just doesn't work
right.
On Thu, Jul 28, 2011 at 1:17 PM, Tobias S wrote:
> Ah ok. Maybe then, if such a language mechanism is implemented it
> might be nice when it would be overwritable from command line with a
> parameter :-) E.g. whe
Found this
http://www.indigorose.com/webhelp/sufwi/HowTo/Control_Feature_Installation_Using_a_CheckBox.htm
You would need to translate it to WiX. I can imagine that a similar technique
could be used to control feature installation using radio buttons.
Edwin G. Castro
Software Developer - Staff
> > By now it should be clear what I'm trying to do. A feature dialog is
> > being executed *after* CostFinalize and therefore *before*
> > ExecuteAction. This dialog determines the set of features to be
> > installed. But the actual installation ignores this information. I
> > know why, because it
> -Original Message-
> From: Peter Stein [mailto:pst...@instec-corp.com]
> Sent: Thursday, July 28, 2011 4:14 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5
>
> Not sure why this is so difficult to unders
Not sure why this is so difficult to understand. The installer has components
that are safe to install in some environments/contexts but not in others. Yes,
the installer could be decomposed into multiple installers each of which only
installs a single feature but that's just plain goofy as the
> Yes it does because there are installation scenarios where having the
> superset installed is potentially dangerous.
So, a user could still select the superset (exclusively) and still end up in a
"potentially dangerous" scenario... I don't think mutually exclusive options
help you here. Detect
" Why must you model the features with an exclusive mode."
" I mean, does it really hurt anything (or confuse anybody) if both features
are selected?"
Yes it does because there are installation scenarios where having the superset
installed is potentially dangerous.
" How exactly do you depend o
Why must you model the features with an exclusive mode. That's part of your
problem. Let go of that requirement and let Windows Installer do most of the
heavy lifting for you. You said there's a subset/superset relationship that can
be directly modeled using Feature composition. Use that and mak
It was easy to test but unfortunately the command is still executing.
BTW I have tried moving it around in the execute sequence, mostly between
InstallInitialize and InstallFinalize and I have also converted it to an
execute ="immediate" ca as well - but in every case it still executes.
On Thu, J
Ah ok. Maybe then, if such a language mechanism is implemented it
might be nice when it would be overwritable from command line with a
parameter :-) E.g. when the bootstrapper is called from a CD Browseer
2011/7/28 Rob Mensching :
> Not yet. However, I am considering getting the code to match the
I don't understand all of your explanation starting with "The key here...".
I get what you are saying about the nesting of the features. I was already
aware of that as I have the book by Nick Ramirez.
However that does not solve the problem. The user still needs to select either
FeatureA or Fe
Paul,
Just a guess here but is it valid to mix and match CData sections?
IE, you could try changing:
AND (NOT REMOVE~="ALL"
OR UPGRADINGPRODUCTCODE)
to
-Original Message-
From: Paul Brook [mailto:brook.p...@gmail.com]
Sent: Thursday, July 28, 2011 2:42 PM
To: General discussion
I have several deferred Custom Actions that are conditioned to run only on
XP or W7
All are using a variation on the same condition either
for W7 or Vista
or
for XP
Just to ward off any comments about Win 2000 and older this installer is
targeted for
hardware that our company makes and distribute
Suppose you have the following components:
* ComponentA
* ComponentB
* ComponentC
* ComponentD
Suppose that we want FeatureA (subset) to install only ComponentA and
ComponentB.
Suppose that we want FeatureB (superset) to install everything in FeatureA
*and* ComponentC and ComponentD.
FeatureB {
The registry key exists so the setup will resume after restart or system
failure.
Interestingly, Forefront doesn't complain on any of my machines or VMs.
On Thu, Jul 28, 2011 at 5:09 AM, Roy Chastain wrote:
> > Which auto-start?
> It is installed in
> HKEY_CURRENT_USER\Software\Microsoft\Window
Is it possible to organize your Components so that one Feature has most
Components and the other Feature has less Components? A Component can be
installed by two Features. Maybe I'm misunderstanding.
BTW, deleting files that the Windows Installer thinks should be installed is
a *very bad* design.
Not yet. However, I am considering getting the code to match the current
user locale with a fallback language. I do not really want to create a
dialog box to select a language up front.
On Thu, Jul 28, 2011 at 7:33 AM, Tobias S wrote:
> Hi,
>
> will the following scenario be possible with burn:
I'm not attempting to upgrade anything. I'm trying to use this mechanism to
solve a problem with feature set installation (which I described in another
email).
Basically my installer users can choose between 2 features in a dialog. The
problem is that the dialog choice is not available at the t
Hi,
will the following scenario be possible with burn:
Have a "Select Language" dialog to select the current language for
Burn and then show the Burn UI + License Agreement in the selected
language ? All without creating an own custom UI, mean using
WixStandardBootstrapperApplication.RtfLicense o
There could be something wrong with your sql script. Try replacing the script
with the simplest possible SQL statement and install that.
-Original Message-
From: Nangai [mailto:thangananga...@iinterchange.com]
Sent: 28 July 2011 13:38
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-
Yes. Verbose log message shows that the component is installed. I have no
idea to solve this problem.
>From verbose log:
MSI (s) (54:D4) [12:59:25:411]: Component: ProductComponent; Installed:
Local; Request: Local; Action: Local; Client State: Local
--
View this message in context:
http:
Thanks,
I've created bug "Bootstrapper failed to launch signed installer (no WWW)"
with ID: 3380917
https://sourceforge.net/tracker/?func=detail&aid=3380917&group_id=105970&atid=642714
Cheers,
Thomas
Von:Tobias S
An: "General discussion for Windows Installer XML toolset."
Datum:
> Which auto-start?
It is installed in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\{b0bac50
7-b964-4cf0-9060-5aa68a43aec8}
The data is
C:\ProgramData\Package
Cache\{b0bac507-b964-4cf0-9060-5aa68a43aec8}\WiX36.exe /burn.log.append
"c:\temp\WiX_Toolset_v3.619922.0_x.log" whe
issues can be opened at
http://sourceforge.net/tracker/?group_id=105970&atid=642714 (or link
on http://wix.sourceforge.net/ right hand side below Support). Then a
registration at sourceforge is necessary and you can report a bug...
2011/7/28 :
> Hi,
>
> I've tried now to install on a real system
Hi,
I've tried now to install on a real system without internet connection and
not having the signatures of the PostgreSQL setup installed before.
But the bootstrapper failed to launch the nested setup as well, but have a
different error number (0x80096005).
[0640:12D0][2011-07-28T09:45:09.734
Actually I also was the oppinion that
Microsoft.Deployment.WindowsInstaller.Installer.EnableLog(InstallLogModes.Verbose,
logFile + ".install.log");
does the same as /L*v. At least I use ith for my implementations that way.
When doing a short diff with winmerge I mentioned just the
"Property(S)"
You should only need InstalLogModes.Verbose. I'm assuming DTF just maps to
the values for MSIEnableLog, as I do in my home-grown version.
See the "verbose" value under
http://msdn.microsoft.com/en-us/library/aa370091%28v=vs.85%29.aspx
-Original Message-
From: Castro, Edwin G. (Hillsboro)
31 matches
Mail list logo
