upgrade table ActionProperty and removing old versions
Mike Blake-Knox
difficulties having the VS Installer remove old versions. It appears
that part of the problem is that a higher version (of project, .exe and
.dll files) was used in an old version. A solution would be to have two
rows in the upgrade table to specify two min and max version number
ranges for old products. From the Upgrade Table writeup, it appears
that I also need two different ActionProperty values.
I don't understand how a value of the ActionProperty field results in
removing an old version of a product. There is obviously some logic
somewhere that causes the Windows installer to remove the old version
when particular values are found in the ActionProperty field. Where is
this described? The ActionProperty field is currently
PREVIOUSVERSIONSINSTALLED which shows up in the SecureCustomProperties
property. How does this result in an uninstall?
Also, we would like to a complete uninstall of the old version rather
having individual modules versions being used.
Mike Blake-Knox
Phil Wilson
that would prevent your product version from replacing that higher version
that's already been shipped. The user would need a manual uninstall.
Those ActionProperty values don't by themselves do anything, but if you wanted
to condition a custom action on the fact that you were replacing a previous
version you could use them in conditions.
--
Phil Wilson [MVP Windows Installer]
----
"Mike Blake-Knox" <mikeb...@spamintrex.net> wrote in message
news:VA.0000004...@spamintrex.net...
> I've inherited a Visual Studio C# application and am having
> difficulties having the VS Installer remove old versions. It appears
> that part of the problem is that a higher version (of project, .exe and
Mike Blake-Knox
> You might be able to use the DetectNewerInstalledVersion VS project property -
> that would prevent your product version from replacing that higher version
> that's already been shipped.
We actually want to remove the files that have a specific range of version
numbers (i.e., 1.1.0 to 1.1.1) that are higher than the current version numbers
of our product (i.e., 1.0.19). It seems to me that an additional row in the
upgrade table specifying min/max version numbers of 1.1.0/1.1.1 could be used to
set a property to have the older product removed. What I don't understand is how
Visual Studio .NET uses the value in the ActionProperty column
(PREVIOUSVERSIONSINSTALLED that I can see via Orca to cause the previous version
to be removed. PREVIOUSVERSIONSINSTALLED shows up only in the Upgrade table and
the SecureCustomProperties property and yet old versions of the product are
(partially anyway) removed. It does NOT appear in the InstallExecuteSequence
table.
Can you explain how this works and/or give me a pointer to find the answer for
myself?
Incidentally, the behavior occurs when all installs were done for "Me Only".
Thanks.
Mike Blake-Knox
Phil Wilson
upgrade to occur. The properties that are set don't do anything except as
conditions you can use later. DetectNewerInstalledVersions DOES create another
row in the Upgrade table, the only difference from the "uninstall older product"
case is that it doesn't do the remove because the
msidbUpgradeAttributesOnlyDetect bit is set. The property that
DetectNewerInstalledVersions eventually sets in the Upgrade table table is used
to condition a Type 19 custom action that terminates the attempt to install
lower product version over higher.
--
Phil Wilson [MVP Windows Installer]
----
"Mike Blake-Knox" <mikeb...@spamintrex.net> wrote in message
news:VA.0000004...@spamintrex.net...
Mike Blake-Knox
In article <#Rc7K#tAEHA...@tk2msftngp13.phx.gbl>, Phil Wilson wrote:
> Internally, it's FindRelatedProducts and RemoveExistingProducts that cause the
> upgrade to occur.
>
So the blank condition field in my InstallExecuteSequence means
RemoveExistingProducts is run each time but does nothing on these particular
files as their numeric version is higher than that of the new file. (Apparently
we had a version number mistake several builds back that resulted in several
files with version strings higher than the current version). The
PREVIOUSVERSIONSINSTALLED property set in the Upgrade table of Visual Studio
generated installers is not actually used (but is available for use if some
action required it as a condition).
Is this the underlying problem? Does it override the "a" in the reinstallMode
property? Is it possible to have the installer completely remove an old product
even though one or more existing components has a higher version than the
corresponding current component? This would avoid us requiring the customer to
manually use the Add/Remove Programs control panel to remove the product. (This
seems to work well and even deletes the product folder).
Thanks.
Mike Blake-Knox
Phil Wilson
version. Setting RemovePreviousVersions True causes VS to generate Upgrade table
entries to remove the older product.
DetectNewerInstalledVersions is a feature of VS designed around the assumption
that most customers don't want to accidentally downgrade a higher versioned
product.
REINSTALLMODE doesn't matter in a major upgrade (which is what
RemovePreviousVersions causes) because the old product is uninstalled and then
the new one installed. There are no file version replacement issues in
VS-generated uses of RemovePreviousVersions because of its sequencing of
RemovePreviousVersions - uninstall followed by install. There's no reason why
you can't manually edit the Upgrade table to set VersionMin, VersionMax and
Attributes to remove everything in the range you want removed - you just can't
do it in VS because the IDE doesn't expose VersionMin, VersionMax etc.
--
Phil Wilson [MVP Windows Installer]
----
"Mike Blake-Knox" <mikeb...@spamintrex.net> wrote in message
news:VA.0000004...@spamintrex.net...
Mike Blake-Knox
> It's not file versions that matter in RemovePreviousVersions, it's the product
> version.
I think you mean the product version of the individual files. Is this right?
> There are no file version replacement issues in
> VS-generated uses of RemovePreviousVersions because of its sequencing of
> RemovePreviousVersions - uninstall followed by install.
This seems to mean uninstall followed by install of *files/components* as
opposed to uninstall followed by install of *the complete product*. Is this
right?
The VS generated upgrade table flags the current product version as both
NEWERPRODUCTFOUND and PREVIOUSVERSIONSINSTALLED. Suppose I use the VS rebuild
command twice to build two msis then install the first one. If I try to run the
second installer (without removing the product), the installer reports "Another
Version of this product is already installed. Why is this?
Incidentally, the deployment project is a subproject; it is a sibling of several
other subprojects, one for each dll/.exe that is built.
Thanks.
Mike Blake-Knox
Phil Wilson
--
Phil Wilson [MVP Windows Installer]
----
"Mike Blake-Knox" <mikeb...@spamintrex.net> wrote in message
news:VA.0000004...@spamintrex.net...
> > It's not file versions that matter in RemovePreviousVersions, it's the
product
> > version.
>
> I think you mean the product version of the individual files. Is this right?
[[[
No I mean the version of the product, the Version property in the project
properties which becomes the ProductVersion in the MSI file.
]]]
> > There are no file version replacement issues in
> > VS-generated uses of RemovePreviousVersions because of its sequencing of
> > RemovePreviousVersions - uninstall followed by install.
>
> This seems to mean uninstall followed by install of *files/components* as
> opposed to uninstall followed by install of *the complete product*. Is this
> right?
[[[
No, not really.
The VS generated major upgrade sequences RemoveExistingProducts so that the
previous product is uninstalled and then the new product is installed.
Consequently file versions are irrelevant - it's pretty much the same as if the
user uninstalled the old product and then reinstalled the new one. It involves
files and components, sure, but that's a level of detail where you don't need to
go for a VS major upgrade. There are other places you can sequence
RemoveExistingProducts such that file versions *do* matter, but that's not what
VS setups generate. RemovePreviousVersions in VS causes a major upgrade with a
sequence position of RemoveExistingProducts that uninstalls the old product then
installs the new one. Stop thinking that you're in some file-by-file replacement
mode because you're not.
]]]
> The VS generated upgrade table flags the current product version as both
> NEWERPRODUCTFOUND and PREVIOUSVERSIONSINSTALLED. Suppose I use the VS rebuild
> command twice to build two msis then install the first one. If I try to run
the
> second installer (without removing the product), the installer reports
"Another
> Version of this product is already installed. Why is this?
[[ Because it's true. The product is identified by the ProductCode guid, and
it's already installed, and you're trying to replace it with an MSI file with a
different PackageCode. Therefore you must be trying to update it somehow, but
you've not defined how. Typically you'd be doing a minor upgrade specifying
REINSTALL=ALL REINSTALLMODE=vomus on the command line, but I don't believe doing
this with VS is a good idea - I don't know if they support it. A minor upgrade
has rules about component guids and component content that aren't exposed in the
VS IDE. This is why there are fully featured products from InstallShield, Wise,
Zero G, etc etc. ]]