Hello? Anyone know how to get at that file? I've never seen it anywhere,
neither in my wixproj project nor in any output folder. I'm setting these
DisplayName values in a wxs file, within MsiPackage elements...
-Original Message-
From: Alexander Krivács Schrøder [mailto:alexander.schro
Okay, thanks. Next (and obvious) question then is how do I get at that file
(wherever it is) from inside the bootstrapper?
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 26. September 2012 16:30
To: General discussion for Windows Installer XML toolset.
How do you get a hold of that information within the bootstrapper? Most of the
EventArgs given in the BootstrapperApplication class events only contain
PackageId, and I've looked through the BootstrapperApplication, Command and
Engine classes without finding any way to get from package ID to
for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get heat.exe to harvest
There is a way... I just don't remember what it is. smile/ Can you open a bug
to have it documented?
On Wed, Apr 18, 2012 at 1:04 AM, Alexander Krivács Schrøder
alexander.schro...@mermaid.no wrote:
I'm using
version of the WiX toolset are you using? Harvesting is off by default in
WiX v3.6 since it caused so many random problems in people's builds.
We're investigating how to bring it back in WiX v4.
On Tue, Apr 17, 2012 at 4:37 AM, Alexander Krivács Schrøder
alexander.schro...@mermaid.no wrote
in the
package cache. Packages are always securely placed in the package cache to
ensure they are not tampered with before being executed. If you say Cache=no
the files will be deleted from the cache at the end of the Apply phase.
On Tue, Apr 17, 2012 at 2:17 AM, Alexander Krivács Schrøder
Hi.
On packages in Burn, you can set a DownloadUrl, which gets downloaded as
necessary during installation. In my custom bootstrapper, I'd like to show some
progress during this download so that my users don't just have to sit there
while nothing happens for potentially many minutes on a slow
Hey.
I'm having some issues with heat.exe/harvesting. I've set Harvest=True on one
of the referenced projects and ProjectOutputGroups=Content, but when I build,
heat.exe is never run. Only candle.exe and light.exe are run, and light.exe
fails with this message, which is not that surprising,
I have, in the bootstrapper I'm making, the need to send a quiet command to
two MSIs, as they will otherwise show GUIs in addition to my bootstrapper GUI.
Is there a way to do this? With msiexec you just send in /quiet as a command
line, but I see no corresponding setting on the MsiPackage
@lists.sourceforge.net
Subject: Re: [WiX-users] BootstrapperApplication.DetectMsiFeature not fired
On 06-Feb-12 06:44, Alexander Krivács Schrøder wrote:
I'm using the WiX v3.6 Beta (v3.6.2221.0) here. This functionality has worked
before, but now, the DetectMsiFeature event does not fire at all
they have the same component
guid).
BTW Permanent really means permanent. It's a setting in the project, but once
you install a component that's permanent it's permanent on the system. Why
expect it mean not permanent?
Phil W
-Original Message-
From: Alexander Krivács Schrøder
I'm using the WiX v3.6 Beta (v3.6.2221.0) here. This functionality has worked
before, but now, the DetectMsiFeature event does not fire at all upon calling
Engine.Detect(). Other related events, like DetectPackageComplete and
DetectRelatedMsiPackage do fire. Is this a known problem?
Just as an FYI, I now updated WiX to v3.6.2603.0, but the issue is still
present.
-Original Message-
From: Alexander Krivács Schrøder [mailto:alexander.schro...@mermaid.no]
Sent: 6. February 2012 12:44
To: wix-users@lists.sourceforge.net
Subject: [WiX-users
Hey.
In implementing my own bootstrapper application, I've implemented the
DetectRelatedMsiPackage event to be informed of MajorUpgrades if an msi with a
lower version number is installed, and this works fine. However, the
RelatedOperation enum also contains a value called Downgrade, but when
Hey.
I have a question regarding the XmlFile element. In my installer, I'm using it
to modify a Unity configuration in an existing installation of another program
(I'm replacing one plug-in with another). The way I'm doing it looks like so:
util:XmlFile Permanent=no Id=SetPlugin
of Burn are you using? Can you share out the detect section of the
Burn log file?
On Mon, Jul 4, 2011 at 4:58 AM, Rob Hamflett r...@snsys.com wrote:
Ah. I haven't looked at Burn. Sorry. Hopefully someone else has the
answer to that one.
Rob
On 04/07/2011 12:13, Alexander Krivács Schrøder
Hey.
According to the Windows Installer specifications, we change the Product Code
of our product with every release (We just use Product Id=* ... /) and we
keep the Upgrade Code the same. That way, when the individual MSIs are run, if
any previous versions exist, they are first uninstalled.
to call it from C#. I
don't know if you're using C# or VB, but a bit of searching around that
function name should get you there.
Rob
On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
Hey.
According to the Windows Installer specifications, we change the Product Code
of our product
Hey.
Thank you for your answers, Rob and Vadym. Vadym's suggestion of setting the
installers to ALLUSERS=1 fixes the problem. My question is thus: Why doesn't
the ProductCode detection work without setting ALLUSERS=1?
As for your question, Rob, I'm not installing an MSI from outside the
Hey.
How does the detection mechanism in the WiX bootstrapper work?
I have two MSIs, both of which are made with WiX. One of them is detected by
the bootstrapper, the other isn't:
[119C:1814][2011-06-17T11:32:33.849+01:00]: Initializing string variable
'MbaNetfxPackageId' to value
20 matches
Mail list logo
