I suspect I'm stuck but thought I'd ask.
I have two existing MSIs, call them Base.msi and Dell.msi. They install
separate facets of my product - the base files, then additional files
needed to support particular Dell hardware.
I now want to create a new single MSI that replaces Base.msi and
...)
Date: Thu, 28 Nov 2013 13:39:39 -0500
From: michael.ogil...@pixelink.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrades
Hello Phil,
Thanks for the info.
From the log files it looks like it uninstalls the stuff twice.
From the install logs of the MSI it goes through
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Wednesday, November 27, 2013 10:54 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrades
Generally yes, although you might not specify all of those attributes.
Each
MSI needs some information
Generally yes, although you might not specify all of those attributes. Each
MSI needs some information instructing it how to process upgrades, which is
independent of how the MSI is launched, as part of a bundle chain or
directly.
--
View this message in context:
Do you need to include this MajorUpgrade
Schedule=afterInstallValidate DowngradeErrorMessage=A newer version
of this application is already installed. AllowDowngrades=no/ in
each MSI if you wrap all of the MSI's in a burn bundle?
Thank you,
Michael Ogilvie
Hi folks,
I have a few installers that I am writing in WIX 3.7
I was just using:
MajorUpgrade Schedule=afterInstallValidate AllowDowngrades=no
DowngradeErrorMessage=A newer version of $(var.PlatformProductName) is
already installed. Setup will now exit. /
To handle upgrades (uninstall older
That's just setting a bunch of properties. If you don't use the properties,
you don't need all that. MajorUpgrade element is all you need (plus change
Product/@Id and do not change Product/@UpgradeCode).
On Tue, Apr 2, 2013 at 6:01 AM, StevenOgilvie sogil...@msn.com wrote:
Hi folks,
I have a
Thanks Rob Thought so...
Steve Ogilvie nbsp; “Our lives begin to end the day we become silent about
things that matter.”, Dr. Martin Luther King Jr. Sent from my
Hi all,
I have implemented upgrades by doing the following (I have an include file
that has the product/package properties which I define and include the
include file :)...
Product Id=$(var.ProductCode)
Name=$(var.PlatformProductName)
Language=1033
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: 20 December 2012 18:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrades NOT working on a new install
Hi all,
I have implemented upgrades by doing the following (I have an include file that
has
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
You seem to have the MajorUpgrade element and also the Upgrade element,
MajorUpgrade replaces the need for manually authoring the upgrade table. Also,
I wouldn't hard code Product/@Id just
www.fiserv.com
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Thursday, December 20, 2012 11:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Okay,
I now have
number
(higher) and the ProductCode is different...
Steve
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: December-20-12 2:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new
: Re: [WiX-users] Upgrades NOT working on a new install
Okay I changed the ProductCode to be * as well as the Package Id=*
First MSI had a version number of 4.0.1.25 second MSI has a version number
of 4.1.2.55
When I run the second it's like the first one was not installed, it was like
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Okay I changed the ProductCode to be * as well as the Package Id=*
First MSI had a version number of 4.0.1.25 second MSI has a version
number of 4.1.2.55
When I run the second it's like
: [WiX-users] Upgrades NOT working on a new install
What do you mean by When I run the second it's like the first one was not
installed, it was like running a fresh install? Does the verbose log tell
you whether 4.0.1.25 was detected and uninstalled? I guess I should also ask
the obvious
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 20 December 2012 19:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Okay,
I now have:
Product Id=$(var.ProductCode)
Name
Correction - use MajorUpgrade Schedule=afterInstallValidate it will be
simpler.
-Original Message-
From: Neil Sleightholm
Sent: 20 December 2012 21:06
To: General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Upgrades NOT working on a new install
Use
]
Sent: December-20-12 4:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Correction - use MajorUpgrade Schedule=afterInstallValidate it will be
simpler.
-Original Message-
From: Neil Sleightholm
Sent: 20
:)
Steve
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: December-20-12 4:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Correction - use MajorUpgrade Schedule
I am not sure why you would need this, it is not something I have needed.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 20 December 2012 21:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working
/ and
http://www.joyofsetup.com/2010/01/16/major-upgrades-now-easier-than-ever/ )
Neil
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 20 December 2012 21:53
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrades NOT working on a new install
Not sure what you mean by extra code, this is what an upgrade looks like. Using
afterInstallValidate will uninstall and then install, using afterInstallExecute
will replace files (not a good
The code below clears out previous versions for me.
Product Id=23cc363c-b9d2-451b-a349-38b91bd487c6
Name=Common 1.0.4.0
Language=1033 Version=1.0.4.0
Manufacturer=Company Name
UpgradeCode=9d32a378-0b1e-492a-9a40-dd80deb8ab55
...
Property
...@imass.co.uk]
Sent: 09 March 2009 13:37
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrades
The code below clears out previous versions for me.
Product Id=23cc363c-b9d2-451b-a349-38b91bd487c6
Name=Common 1.0.4.0
Language=1033 Version=1.0.4.0
I've got a program that I need to upgrade. I saw a post here, which I
thought explained how to do it.
However, for every upgrade I perform, it shows up as a new entry in the
Add/Remove Programs.
I've included what I think is the relevant markup. Thanks in advance for
any insight.
Product
Two thoughts that I have.
1. Your SetCAP_RestoreWebConfig custom action is sequenced at 265. Has the TargetDir property been determined by Windows Installer at this point? If it hasn't, then you're going to be getting a blank TargetDir value. Im not real sure of when that happens, but that's a
Hey all,
I'm trying to implement handling for major upgrades for a web application
installation.
The use case I'm currently testing is:
1. User installs v1.0.0 of the application
- Install gathers information about the virtual
directory and database server
- App is
Hi,
I have a known problem with major upgrades and just want to be sure that there
is really no solution for it.
I have an MSI file with a user-interface that gives the choice to install for
all users or only for current user. When the user installs a new version of the
product there should
29 matches
Mail list logo
