Hello,
i am using the wix toolset v3.8 with Visual Studio 2013 Pro to produce
Setups for our software.
The user should be able to install multiple versions of our software.
In some versions the bootstrapper use the same packages at installation.
The problem here, now if you uninstall a version
I want to have two equivalent bundles: one that has the .net framework included
(as wix calls it, compressed), and one that will download it. I'm currently
creating the two bundles from a single bundle file by using an that I
pass on the command line. Everything works fine except during install
You are correct... You cannot upgrade a 32 bit package with a 64 bit
installer. Out of curiousity, do you have any install conditions?
As a side note, the program files in the (x86) are stored in a
different registry than their 64 bit counterparts, hence the reason
the upgrade was failing.
Yeah, the "bitness" was just used as an example. In reality, they are DMS
client DLLs (OnBase). You can either choose "Version 12" or "Version 13" in
the installer, so depending on which one they choose, the src value is
different, but the name of the files are the same :(
We tried the route, whi
A general comment, without knowing exactly what the requirements are,
and if you really are doing different bitness files in a single MSI,
different packages are recommended for different architectures.
Heath's article:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-requ
Yes, I had dug into the MSIs until my (virtual) fingernails bled! Everything
looked normal.
So it turned out that the client package that I was working against is a really
old one, and machines that we will be upgrading will actually have a later
version. I tried the later version, and my MSI u
The MSBuild v120 PlatformTools portion of my problem was resolved when I
reconverted my C++ project from VS2010 to VS2013 so that the
ToolsVersion="12.0" rather than ToolsVersion="4.0" at the top of the project
file. So my MSBuild v120 PlatformTools had been installed correctly after all.
My MS
If FindRelatedProducts had found anything it would have said so there,
so I'd do a sanity check on the usual suspects, use Orca on the MSI
files if you need to verify against MSDN docs. Also, the log would
show OLDPRODUCTS being set.
UpgradeCode the same in both products.
New product has a differe
What are my options to proceed with this then to behave like I'd like?
Is there a way to force individual components to reinstall, to force the
checking of the ?
Can I conditionally change the install state of a component, rather than
using a to drive it? Then rather than setting a property I
fl
We use VS2013 and heat to harvest files and registry information. I have not
used it to harvest a VS project file, as discussed in the bug. The bug also
does not indicate that the reported issue is related to missing MSBuild v120
PlatformTools. that seems to be a different issue, but I could be
I now see that Bug 4279 (http://wixtoolset.org/issues/4279/) acknowledges that
Heat does not work on VS2013 .vcxproj files. (After re-converting my C++
project to VS2013, I get the same results reported in Bug 4279)
Is there any way to tell which future release of Wix Heat is slated to be
compa
I have removed the GAC dependency, as this seems to be the best approach...
Thanks for the idea.
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: April-15-2014 4:38 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Service Start Too Ear
I have to ask again, because I have to make a decision soon.
Is there any important point that speaks against modifying the MSI database
after build, if it happens in a controlled environment?
As a simple example:
--> A MSI package including a property called "configValue=1"
--> My tool changes t
13 matches
Mail list logo
