Uhh, don't do that? Burn doesn't support it today. "a" is a pretty brutal
setting, it would downgrade files and such.
On Thu, Jan 3, 2013 at 8:25 AM, Gustavo Gustavo wrote:
> Hmm, yep, it really works. But, what if I need to pass in
> REINSTALLMODE=vamus and not vomus? Setting a MsiProperty doe
Hmm, yep, it really works. But, what if I need to pass in
REINSTALLMODE=vamus and not vomus? Setting a MsiProperty does not do the
trick.
Em 03/01/2013 12:35, "Rob Mensching" escreveu:
Burn should automatically detect when you are doing an minor upgrade and
pass the appropriate switches for you.
Burn should automatically detect when you are doing an minor upgrade and
pass the appropriate switches for you.
On Thu, Jan 3, 2013 at 3:57 AM, Gustavo Gustavo wrote:
> Hi,
>
> I need to implement minor upgrades - same ProductCode for my software
> releases.
>
> The problem is that when it's a
Hi,
I need to implement minor upgrades - same ProductCode for my software
releases.
The problem is that when it's a fresh new installation it's enough to
double click the .msi (or msiexec /i ).
But, when it’s an upgrade, then I need to msiexec /i
REINSTALL=ALL REINSTALLMODE=vomus only.
I would
1. IIRC, (I try to avoid CopyFile so I could be mistaken) uninstalling an
MSI does not remove the copied content. You could create a quick MSI to
verify.
2. I highly recommend making your scripts idempotent. Thus, you can always
run them and if they've already been applied, they do nothing. Makes
Hello folks,
as I did not get any answers to my last question, I try to be more precise
today.
I want to make an Installer with burn, that installs quite a big application.
So there are different things to do, like just install some files, copy some
files around, initiating a database and so o
On Thu, 14 Jan 2010 15:16:05 -0500
"Castro, Edwin G. (Hillsboro)" wrote:
> We have an automated build that runs continually. We'd like each MSI
> produced to behave as a major upgrade so that we can apply any newer
> MSI on a target environment easily. Our build process fixes the first
> two part
ject: [WiX-users] Major Upgrades and Versions
We have an automated build that runs continually. We'd like each MSI produced
to behave as a major upgrade so that we can apply any newer MSI on a target
environment easily. Our build process fixes the first two parts of our version
n
We have an automated build that runs continually. We'd like each MSI produced
to behave as a major upgrade so that we can apply any newer MSI on a target
environment easily. Our build process fixes the first two parts of our version
numbers to predetermined values and allows the remaining two va
o:tart...@tartley.com]
> Sent: Wednesday, September 30, 2009 9:07 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] major upgrades just reinstall, overwriting previous
>
> Ah, good question. The version that ultimately ends up installed is
&g
ress bar as the
only widely noticeable side effect.
-Original Message-
From: Jonathan Hartley [mailto:tart...@tartley.com]
Sent: Wednesday, September 30, 2009 9:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] major upgrades just reinstall, overwriti
Ah, good question. The version that ultimately ends up installed is
indeed the new version.
A moment reflecting on your response makes me think that maybe I have
confused myself by expecting to see some change to the UI during an
upgrade, as opposed to during a fresh install, and perhaps this i
> It does not remove the old version. It overwrites the old install, and after
> it is done, there is
only one item listed in 'Add or Remove Programs'.
I'm not sure I understand this. What do you mean by "it does not remove the
old version?" Because
you then say that it overwrites the old
Incidentally, my Component Guids are all hard coded and constant.
Jonathan Hartley wrote:
> Hi all.
>
> I'm trying to add major updates. (Actually I'm migrating our Wix config
> from 2 to 3, and I can't see what I did to break major updates in the
> process.)
>
> I followed the tutorials and rea
Hi all.
I'm trying to add major updates. (Actually I'm migrating our Wix config
from 2 to 3, and I can't see what I did to break major updates in the
process.)
I followed the tutorials and read the docs at (and many others)
http://www.tramontana.co.hu/wix/lesson4.php#4.1
http://wix.sourceforge.
Windows Installer defines the UPGRADINGPRODUCTCODE property when a product
is being removed as part of a major upgrade. A typical condition you might
use is "NOT UPGRADINGPRODUCTCODE".
- Don Benson -
On Thu, Apr 16, 2009 at 8:00 AM, Jeff Reed wrote:
> I apologize about the previous post. I didn
I apologize about the previous post. I didn't trim it down to just minimal
text. After this 2nd question, I'll shut up for a while. :)
Hi everyone,
In the Wix tutorial, it indicates that (among other things) changing a
component ID forces the MSI to be a major upgrade (meaning package GUID,
eral discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrades without version change
>
> That is one view of version numbers but it doesn't work for me. It
> relies on there being a single source of the build number, if two
> builds are started
ples approaches.
Neil
-Original Message-
From: Castro, Edwin (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: 12 March 2009 20:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrades without version change
System.Version defines the f
ilto:n...@x2systems.com]
> Sent: Thursday, March 12, 2009 1:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrades without version change
>
> I don't think that is that case as my RemoveExistingProducts is
> scheduled at
Sleightholm
X2 Systems Limited
n...@x2systems.com <mailto:n...@x2systems.com>
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Thu 12/03/2009 00:06
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upg
t.
Subject: Re: [WiX-users] Major Upgrades without version change
Good point, that could even be considered a useful feature "downgrades"
without an uninstall.
Neil
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: 11 March 2009 17:20
To: General di
Good point, that could even be considered a useful feature "downgrades"
without an uninstall.
Neil
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: 11 March 2009 17:20
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Majo
Neil Sleightholm wrote:
> This works but is it a really bad thing to do?
>
It means that it's still possible to install an "earlier" version. If
they're never released, it's only a problem for your internal folks.
--
sig://boB
http://joyofsetup.com/
In common with a lot of build processes ours uses a 4 part version
number, major.minor.day.revision, in a given day the revision can change
if the developers rebuild but the shipping product would never have the
same major.minor.day version. This causes a problem with Windows
Installer major upgrad
Ian Elliott (Excell Data Corporation) wrote:
> If I condition out the component that contains the scripts, it doesn't get
> installed during major upgrade. I see in the log that ComponentRegister then
> registers that component as State=-7. When you finally uninstall, the
> component does not ge
I have some sql scripts that should only be run on initial install and never
again. Unfortunately, before this was released, the scripts were in such a
state such that they couldn't detect that they had already been run. So, when
the component installs during the major upgrade the scripts run ag
27 matches
Mail list logo
