It persists the Variable for future executions of the Bundle. It is not
currently possible to access persisted Variables for other Bundles
(although I believe there is a bug open to add the functionality for
related Bundles).
On Mon, Jul 9, 2012 at 11:20 PM, Neil Sleightholm wrote:
> What does th
So is that other executions of the same installation e.g. on repair or
uninstall?
What I was after was a way of saving the install folder if someone changes it
so that when they upgrade it installs to the same folder - will I have to do
that in the MSI and read the value back in the bundle?
Ne
Variable/@Persisted makes the "Remember Property Pattern" (
http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Property-pattern)
unnecessary for a single Bundle. What you want is the related Bundle
solution that does not exist in Burn v3.6.
On Tue, Jul 10, 2012 at 12:30 AM, Neil
I couldn't find a bug or feature request for this so I have added one - 3541950.
Neil
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 10 July 2012 08:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bundle Variable Persiste
Hi,
Please find the log file details, while uninstalling the setup.
___
[0F50:177C][2012-07-10T07:05:40]: Burn v3.6.2928.0, Windows v6.1 (Build
7600: Service Pack 0), path: C:\ProgramData\Package
Cache\{7215c
Hi Garrett,
with our product we have some libraries that get installed into .NET
GAC. The GAC they are installed into is defined by the target
framework these assemblies are built for.
So, if you build them for .NET 3.5 or earlier, they are installed into
the .NET 2.0 GAC.
If they are build for .N
https://sourceforge.net/tracker/?func=detail&aid=3542020&group_id=105970&atid=642714
Date: Tue, 10 Jul 2012 00:28:17 -0400
From: Bob Arnson
Subject: Re: [WiX-users] Should balinfo.h be included in sdk/inc?
On 09-Jul-12 17:26, Darwin Baines wrote:
> You can't build WixStdBA without balinfo.h
I see. What would Result.Ok do then in this situation? Is there a place that
lists what the different result codes do, out of curiosity?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-4-pre-req-in-WixNetFxExtension-tp7579058p7579374.html
Sent fr
Thanks. I've eventually figured out what was the problem: not the patching
process, but the way I was trying to generate the transform file. Obviously
the metadata in .wixmst file are not as important as contents of the files.
I could not create patch using only single working copy of project and j
Hmm.
I've discovered the actual problem--which is actually quite a bit more
troublesome.
Indeed, if I don't have a version of that assembly installed, the binary will
get registered in the correct GAC. Unfortunately, if I have a version of the
assembly in the .NET 4.0 GAC, the 2.0 version jus
I'm new to WiX and trying to determine if this tool will work for our purposes.
We're using VS 2010.
In working through the instructions for Creating a Simple Setup under Working
in Visual Studio, it appears that when I build the setup after adding the
reference nothing is added to the Product.wx
The Product.wxs is not modified by the automatic harvest functionality. A new
temporary file in the intermediate directory (obj) is generated and included in
the list of files to compile. This is why the harvested files show up in the
MSI package as expected. Look in the obj directory for genera
Hi Fokes:
I'm just putting together an executable bootstrapper using burn.
I have the following bundle:
http://schemas.microsoft.com/wix/2006/wi";>
When compiled and run, the install f
Your MSI is failing to install:
0x80070666Another version of this product is already installed.
Installation of this version cannot continue. To configure or remove the
existing version of this product, use Add/Remove Programs on the Control
Panel.
On Tue, Jul 10, 2012 at 8:01 PM, Sean Farrow
wr
Hi Rob:
That's strange, Having just checked programs/features, there doesn't appear to
be any entries related to the product.
Aditionally, another user has the following log:
[02BC:0708][2012-07-09T13:32:24]: Burn v3.6.3102.0, Windows v6.1 (Build 7601:
Service Pack 1), path: C:\work\eeb\srrt60\wi
Same error. Search for "error" in the Burn log and you're pretty certain to
find the error. In this case the MSI log file generated may provide more
details.
On Tue, Jul 10, 2012 at 8:41 PM, Sean Farrow
wrote:
> Hi Rob:
> That's strange, Having just checked programs/features, there doesn't
> appe
16 matches
Mail list logo