One option would be to use burn to create a bootstrapper that uninstalls 4.2.0
and then installs 4.3.0 - this would have to assume that the user who installed
4.2.0 is the same user that uninstalls it. In a similar vein there are some
suggestions here
http://windows-installer-xml-wix-toolset.68
I'd like to use Burn to install multiple pre-requisites (VC++ redist, console
app) and two desktop application msi packages. One of these desktop
applications is a client program to be remotely upgraded without elevation.
I have it installing to LocalAppData and major upgrades work fine without
ele
Thank you for your replies. Given that 4.2.0 is a Visual Studio installer and
would have ALLUSERS set to 2, it would mean the 4.2.0 could've installed any
which way on the machine I am trying to upgrade. Like it did here on my
computer, installed 4.2.0 per-user. In addition, from reading at Joy
All $(var.) values are done at compile time. Your example below will
include one block if the platform is x64 and another block otherwise--all at
compile time. Rather than use $(var.Platform), I would recommend using
$(sys.BUILDARCH).
--
John Merryweather Cooper
Build & Install Engineer -
your saying this is at compile time?
I have a variables.wxi include file that I include with my product.wxs
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Need-help-how-to-put-a-condition-on-a-merge-module-in-Produc
That's not going to be very interesting. The $(var.Platform) is going to be
substituted at compile time.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
I use six wixlibs to install seven services with multiple copies of "common"
assemblies in different directories and AppPools. Works great. We only build
one platform now, x64, but we used to build both x86 and x64. Separate
wixlib's and conditionalized source for each platform.
--
John Merr
damn Nabble takes out the condition:
for the component to be installed on X86 machine:
< ! [ CDATA[ NOT(VersionNT64) OR $(var.Platform) = "x86" ] ] >
for x64 machine:
< ! [ CDATA[VersionNT64 OR $(var.Platform) = "x64" ] ] >
--
View this message in context:
http://windows-installer-xml
Hi folks,
I have a Services installer that uses 5 merge modules (no I can't go away
from merge modules to wixlibs not the way our services install we have 5
different services that install a base of same files for each service in a
different directory for each service)...
Currently I have to VS s
A few extra comments:
Windows Installer doesn't do cross-context upgrades. Per-user will not
upgrade per-machine and vice versa.
Some installers, including Visual Studio, set the ALLUSERS property to 2.
This means, as the documentation says, that "the Windows Installer always
resets the value of
It depends. It is often desired to localize changes to one assembly. Even if
the versions of the other assemblies have changed, often the code content has
not changed. This needs to be verified by regression testing and there is some
risk.
That being said, in general, I would prefer to patch
I think your right. I had noticed that phrase, but was not certain of my
interpretation of it. I agree that I don't know why I would ever deploy a
subset of "changed" files in a ComponentGroup. So in that case I guess I am
ready to move on in testing my new setup.
Thanks.
Phil
--
View this me
I think the part you are missing is " all changed components from that fragment
will show up in your patch". I can't imagine only wanting a patch to contain a
subset of changed components.
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Monday, July 29, 2013 1
You might not be able to use the MajorUpgrade element (I haven't tested this),
but if you author your Upgrade/UpgradeVersion elements to find and remove it
you shouldn't have issues. The only down side is if they try to rerun the bad
install after upgrading then that install won't be able to de
Hi,
I have taken over an install project created with Wise Install.
The previous maintainers had accidentally created a second upgrade code for
our main product and released the resulting MSI. Now we have one product
out in the client base with two different upgrade codes. They then managed
to ha
Yes.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: Tom - [mailto:mittegetm...@hotmail.com]
Sent: Monday, July 29, 201
I logged the installation, and the first time in it that the UpgradeCode-GUID
shows up is at the end of the log when registering. What I did find that seems
odd to me is this:
Action start 18:40:42: FindRelatedProducts.
MSI (c) (48:B4) [18:40:42:744]: FindRelatedProducts: current install is
pe
I am relatively new to WiX 3.7 and MSI (and having lots of fun with the great
WiX documentation and information available in the forum). As I get my
BA/msi functional I am trying to review best practices and I came across a
post at:
http://stackoverflow.com/questions/471424/wix-tricks-and-tips
In
Cool. Two things:
1. Let's start the assignment agreement process (
http://wixtoolset.org/about/assignment-agreement/).
2. Let's have this conversation on wix-devs. That's more appropriate.
On Mon, Jul 29, 2013 at 5:38 AM, wrote:
> Hello,
>
> I have been tasked with discovering if I c
Correct the RemoveExistingProducts goes as well.
I would expect scheduling it after afterInstallValidate should give what you
expect. One thing to check is that upgrade code is the same, product code and
package code are different between the two versions (given your previous code
snippet that
Gentlemen,
Thank you for your replies. MajorUpgrade seemed simple enough, so I added this:
Documentation gave me the impression I could remove this portion and so I did:
I've also tried the suggestion on the slightly larger block of code using
Upgrade-element. These two a
Hello,
I have been tasked with discovering if I can get Burn to support multi
instance installs and was wondering if you all could point me in the direction
I should start looking.
Tyler Reid | Operations and Infrastructure | Accenture Software | P&C Insurance
1807 Jones Street | Boliva
MajorUpgrade element is a lot simpler plus you have unrelated code in this
sample.
Neil
>Try the following:
>
>Add upgrade details just above element.
>The following will block install if newer version detected, and will
>remove
>older version if detected.
>
>
> Property="NEWERVERSIO
Try the following:
Add upgrade details just above element.
The following will block install if newer version detected, and will remove
older version if detected.
NOT
Installed
NOT
Installed
NOT
Installed
NOT
Installed
You seem to be missing an upgrade table. The simplest way to add this is
to use MajorUpgrade element and set the attribute appropriately.
Neil
>Hi everyone,
>
>I've got a long-running application we just upgraded to .NET 4.5 and WiX.
>It's had the same UpgradeCode for ages, so I included it in
Hi everyone,
I've got a long-running application we just upgraded to .NET 4.5 and WiX. It's
had the same UpgradeCode for ages, so I included it in my Product-file for WiX.
It installed side-by-side with the existing application. Reading up some, it
seemed like I had to add a directive to remov
26 matches
Mail list logo
