6 replies to this topic

[Penseleit]

I am performing a major upgrade on an installation.

I have set the Upgrade code and do not change it.
I set the ProductCode, PackageCode and ProductVersion to new values with each new build of the product I am installing.
Each of the above values are stored in the Property table.
I include the MigrateFeatureStates and FindExistingProducts Actions
I have RemoveExisting Products scheduled after InstallFinalize, so my upgrade can use the existing registry entries for my users.
(They want an upgrade which retains all of the settings, including Toolbars, Menu items etc, which they had set for the previous version of the product, so my upgrade should not remove the regsitry entries which the previous version had set.)


I am getting this behaviour:
My upgrade completes properly and all files and registry entries are set as they should be, the registry entries are retained from the previous version. If I stop the Upgrade at this point I have no problems.

BUT when the RemoveExistingProducts Action runs, it removes all of my files and registry entries from the Upgrade!!

My components do not have their GUIDs changed between versions.
My files and registry entries are virtually the same between the previous version and the upgrade. All that changes are the contents of the files and their version numbers.

(Before you ask, yes I could have performed a Patch or minor upgrade, but my company will not allow the use of Patches or Minor upgrades)

My question is this:
If I perform a RemoveExisitngProducts Action after the upgrade is complete,
how can MSI distinguish between the upgraded components and the previous components if the component GUIDs do not change?
Surely it will just remove all of the the components resulting in my problem - all of my files and regsitry entries are uninstallled!

Is MSI supposed to have the smarts to distinguish components between one ProdcutVersion\ProductCode and another, even if their Component GUID is exactly the same in both the previous installation and the upgrade?

My workaround has been to put the condition UPGRADINGPRODUCTCODE="" on all of the Actions which remove Files or Registry entries, but I'm sure that this is not the way Upgrades should be done, because one day in an upgrade, I may actually want to remove deprecated Features or components and my workaround has disabled this ability.

Please provide help with your learned advice..

[luke_s]

I am running virtually the same setup as you are, and my files not removed during an upgrade.

Where have you placed RemoveExistingProducts? If it is after InstallFinalize, this should be ok.

Usually, components guids are changed between setups which will cause the files to be remove if you place RemoveExistingProducts after InstallFinalize, but since they are the same in your setup, this cannot be the problem.

Have you run the ugprade with verbose logging?? this should tell you more

msiexec /I "msifile.msi" /L*V c:\msilog.txt

[KapilMarwah]

Yes the installer has the smarts, it maintains component ref counts. So in your case it'll just increment the ref count during the install of the higher version and reduce the count during RemoveExistingProducts.

To maintain user settings from previous version (HKCU keys) set the msidbComponentAttributesNeverOverwrite for the User component installing these settings otherwise the'll get overwritten.

Also if the component GUIDs are properly alligned (same for both versions) then the installer will never remove them if the removeexistingproducts action is after the installfinalize action.

[Penseleit]

RemoveExistingProducts is After InstallFinalize

I've found that my Upgrades used to work as you describe they should, but recently they just went haywire, with the behaviour I've described.

Interestingly, when I log the upgrade, for entries after RemoveExistingProducts, I find that every component has these comments beside it

Either:
Installed: Local; Request: Absent; Action: Null
Or
Installed: Absent; Request: Absent; Action: Null


I'm also getting these messages:
Disallowing uninstallation of component: {4BA266EC-113E-42CF-99A1-C2749BF38A07} since another client exists for all of my installed components.

So no components should be deleted, yet the DeleteFiles action deletes all of my files.

Strangely, I'v also had other wierd situations.
In one case, for example, I had a condition set so that a component was to be installed if the condition was true.
On one build this worked.
The next build, (I had not changed the condition), the component installed the file when the condition was false.
The next build all worked as it should have again!

[Penseleit]

I think I have the answer to my problem.

Running Package Validation checks on my installation, gave me an ICE61 error on the Upgrade Table.

I had my VersionMin set to 5.23.3447 and my VersionMax set to 5.23.3600.
Problem was, my current version is 5.23.3450.

So when RemoveExisitngProducts uses my previous installation (5.23.3447) to uninstall itself, it looks in the Upgrade table and sees that it can upgrade 5.23.3450, so it removes the files and reg entries for that version.

My problem is that we do a nightly build of our source code at 1am and the installer is built in the same process, but there seems no way of automatically incrementing my VersionMax in the Upgrade Table.

Using [ProductVersion] for VersionMax does not work as it needs to be a string in the ProductVersion format, not a Property.

I might have to look into doing a code snippet from the Windows Installer SDK to get around this, but I don't think this will work.

It seems that MSI installations were not designed to be built automatically...

Any suggestions would e helpful...

[Penseleit]

I wrote some VB code to fix my Upgrade table problem with nifghtly builds.
Here it is:

Option Explicit

Sub Main()
Dim p_strCmdLine As String

'Get commandline
p_strCmdLine = Command()
p_strCmdLine = LTrim(p_strCmdLine)

If p_strCmdLine <> "" Then
SetVersionMax p_strCmdLine
End If
End Sub

Sub SetVersionMax(MSIDBPath As String)

Dim p_Installer As Installer
Dim p_InstallerDatabase As Database
Dim p_dbQuery As String
Dim p_dbView As View
Dim p_dbRecord As Record
Dim p_msiProductVersion As String

On Error GoTo ErrSetVersionMax

'Create an instance of Windows Installer
Set p_Installer = CreateObject("WindowsInstaller.Installer")

'Open the database
Set p_InstallerDatabase = p_Installer.OpenDatabase(MSIDBPath, msiOpenDatabaseModeTransact)

'Get the ProductVersion
p_dbQuery = "SELECT * FROM Property WHERE Property='ProductVersion'"

Set p_dbView = p_InstallerDatabase.OpenView(p_dbQuery)

p_dbView.Execute

Set p_dbRecord = p_dbView.Fetch

p_msiProductVersion = p_dbRecord.StringData(2)

'Set VersionMax in Upgrade table
p_dbQuery = "SELECT * FROM Upgrade Where UpgradeCode='{ECF7AE5A-6820-4844-B557-FACEDA256C92}'"

Set p_dbView = p_InstallerDatabase.OpenView(p_dbQuery)
p_dbView.Execute

Set p_dbRecord = p_dbView.Fetch

p_dbRecord.StringData(3) = p_msiProductVersion

p_dbView.Modify msiViewModifyReplace, p_dbRecord

p_dbView.Close

'Commit changes

p_InstallerDatabase.Commit


Set p_dbView = Nothing
Set p_dbRecord = Nothing
Set p_Installer = Nothing
Set p_InstallerDatabase = Nothing
Set p_sumInformation = Nothing

Exit Sub

ErrSetVersionMax:

End Sub

I only have a single record in the upgrade table so don't need to search through records til I find the right one.

Feel free to adapt this to your own needs.

After all of this, I find that i still get my RemoveExistingProducts Action removing my files and registry entries.

This is very frustrating!!

[luke_s]

FYI - I also had the same problem - there was not way to automattically update the codes, and build numbers so i had to write an exe to do this.

I think in the latest version of Install Shield, they allow the automation interface which gives you the functionality to change things like this.