I use a program called MSICREATE to generate msi packages for a piece of software. I then use orca to transform the msi package. Things work ok but users must delete the existing product before installing an update. I'd like to modify the msi package so the installer recognizes a newer or different version is being installed and removes the current version and then installs the new msi package.
What property table entries are needed?
=========
The answer given below has helped me get beyond my original problem and I thank Ciprian for his help. My major upgrade msi now deletes the existing product BUT does not completely re-install the product. My product consists of some text files, a help file, and a .exe file. The .exe file is not re-installed.
For whatever it's worth, I added answer below which summarizes what I added to my msi using orce.
I don't know how MSICREATE handles the upgrade scenario. However you could achieve this using ORCA. Here is a detailed upgrade example from MSDN.
Long story short both your packages must share the UpgradeCode. Also you must author an entry in the Upgrade table of the second package.
Here are the things I added to my msi using orca to effect a major upgrade. As I said above I still have a problem in that my .exe file is not reinstalled on a major upgrade. The .exe is added if one does a repair.
InstallExecuteSequence Table
added FindRelatedProducts with sequence 400
added RemoveExistingProducts with sequence 1450
InstallUISequence Table
added FindRelatedProducts with sequence 200
PropertyTable
added RemovePreviousVersions TRUE
added SECURECUSTOMPROPERTIES SOLARUPGRADE
had a existing UpgradeCode with guid created by MSICREATE
had a existing ProductVersion 12.2.12.0 created my MSICREATE
Added a Upgrade Table
UpgradeCode same value as Upgrade in Property Table
VersionMin null
VersionMax 99.12.31
Attributes 1
ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in
Property Table)
I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.
Related
I have a Visual Studio 2010 Setup Project and I am trying to create an Upgrade to a new version of my software.
The upgrade process is running. I properly updated the Version Number, which caused an update of the Product Code. RemovePreviousVersions is also True.
My problem is that when I upgrade my software, there is one file that may have changed on the local filesystem, in the course of running the software. I'm finding that, because the file changed, the installer refuses to overwrite it.
I want my installer to force this file to be overwritten with the new version.
Is there something I can do -- within Visual Studio, with Orca, or otherwise -- to force a file to be overwritten even if it has changed?
UPDATE: In Orca, I noticed that the "File" table includes a "FileSize" column. I believe this might be the reason the file is being ignored. If the size of the file has changed, it doesn't match. Is there any way to override this?
You can't safely change the Windows Installer replace rules, but you are getting into this situation because the upgrade mechanism first installs the upgrade on top of the older product (invoking file replacement rules) then uninstalls the old product, ref counting down and removing the product. It's the "on top" that is the issue. If you move RemoveExistingProducts in the InstallExecuteSequence from just before InstallFinalize to just after InstallInitialize you will get a complete uninstall of the older product then the install of the new upgrade. That may not work if you are expecting to keep data files around.
Otherwise you could use the RemoveFile table with Orca. You'd add an entry targeting the Component name corresponding to the file (look in the File table, and there may already be some entries in the RemoveFile table as examples). You'd set the value to be Remove on Install. The RemoveFiles action occurs before the new files are installed, so it should work.
I've created a copy of InstallShield project, so all the settings should be the same. (I've done this before with success). I am using this copy to make changes to the installer project as it will be called in an automated build way. One big change I made this version of the installer project was to reference a shared network location for pre-req(s). One pre-req is another installer project that gets built before this, and pulled in the main installer.
I am testing this build locally and not through the automated build process.
I know the upgrade codes match. I have 2 upgrade codes checks for Major Updates. I also check "Any Version" setting as well.
However when I build and test out the new installer it does not remove previous entries.
I have checked here [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall] and see the app listed in there twice. I had really hoped to find the UpgradeCode in order to shed some light if that was getting messed up for some reason or another, no dice.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\installer] <- no dice
As some suggested I have browsed to the exe and tried to add the Major Upgrade item, I still get the same upgrade code.
So my questions is does anyone have anything else to check that might be holding up getting this entry out of the add-remove dialog.
Log File
MSI (c) (D0:E0) [16:26:28:649]: Doing action: FindRelatedProducts
Action 16:26:28: FindRelatedProducts. Searching for related applications
Action start 16:26:28: FindRelatedProducts.
Action ended 16:26:28: FindRelatedProducts. Return value 1.
MSI (s) (2C:68) [14:12:34:706]: Doing action: RemoveExistingProducts
Action 14:12:34: RemoveExistingProducts. Removing applications
Action start 14:12:34: RemoveExistingProducts.
Action ended 14:12:34: RemoveExistingProducts. Return value 1.
Action start 13:48:41: ISSetAllUsers.
MSI (c) (6C:9C) [13:48:41:826]: Invoking remote custom action. DLL: C:\Users\ngates\AppData\Local\Temp\MSID938.tmp, Entrypoint: SetAllUsers
InstallShield 13:48:41: Begin SetAllUsers()
InstallShield 13:48:41: Getting records from Upgrade table
InstallShield 13:48:41: UpgradeCode: {84A5CBA6-9BC8-4E99-B8AE-9327E9B78A34} MinVersion: MaxVersion: 6.38.0.448 Language: Attributes: 257
InstallShield 13:48:41: Checking related product {AD762BD7-3EA5-4DD2-8552-1474ABED7C6F}
InstallShield 13:48:41: Venus 7000 {AD762BD7-3EA5-4DD2-8552-1474ABED7C6F} 1033 6.38.0.372 ***Related***
MSI (c) (6C!E4) [13:48:41:854]: PROPERTY CHANGE: Adding IS_MAJOR_UPGRADE property. Its value is 'Yes'.
InstallShield 13:48:41: ALLUSERS of related product {AD762BD7-3EA5-4DD2-8552-1474ABED7C6F} is = 1
InstallShield 13:48:41: End SetAllUsers()
Action ended 13:48:41: ISSetAllUsers. Return value 1.
According to documentation(RemoveExistingProducts Action) it appears a return code of 1 means something got removed, so it acts like it's working...
I figured out how to do it!
On the major upgrade item, select the 2nd radio button. And set a appropriate range, for me I did 6.0.0.0 to 6.99.9.9, and that seemed to do it for me. As 7.0.0.0 will constitute a truly major release for us.
I have two products installed. They have the same version number and upgrade code, but different product code. I would like to do a major upgrade on one of these products, but the upgrade exe that I created ends up removing both products, and installing new one.
That being said, how can I keep one product installed when the product has the same upgrade code with the another product that I would like to upgrade?
The Upgrade table first drives FindRelatedProducts. FindRelatedProducts uses the information to perform MSI product searches. If places the ProductCode of a found in the property specified by the ActionProperty column
Later, RemoveExistingProducts performs an uninstall of any ProductCodes found in any ActionProperty properties ( provided that msidbUpgradeAttributesOnlyDetect is not set ).
So the trick out of a sticky situation like this is to author an Upgrade row that will cause FindRelatedProducts to not find either product. Then use a custom action to do your own searches and set the properties as needed ( one but not the other ). Now RemoveExistingProducts will be able to perform the major upgrade.
As a side note: this is a work around and not a best practice. Carefully consider your choice of UpgradeCodes, ProductCodes and ProductVersion properties to avoid this situation in the future.
I have a .msi file created by a program called MSICREATE and doctored using orca as follows...
InstallExecuteSequence Table
* added FindRelatedProducts with sequence 410
* added RemoveExistingProducts with sequence 1450
InstallUISequence Table
* added FindRelatedProducts with sequence 200
PropertyTable
* added RemovePreviousVersions TRUE
* added SECURECUSTOMPROPERTIES SOLARUPGRADE
* had a existing UpgradeCode with guid created by MSICREATE
* had a existing ProductVersion 12.2.12.0 created my MSICREATE
Added a Upgrade Table
* UpgradeCode same value as Upgrade in Property Table
* VersionMin null
* VersionMax 99.12.31
* Attributes 1
* ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in Property Table)
I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.
When I run this msi with the product previously installed, the old product is deleted, a new program files directory created and all the files except the .exe reinstalled from the new .msi. A repair will cause the .exe to be created. If the new msi is installed AFTER removing the old product (using control panel add/remove programs), all files including the .exe are installed.
The msiexec log file is mywebspace.wisc.edu/mdorl/msilog/log3.log
The .msi is mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi
The only things that looks weird to me are the following lines from the log. The first, second, and fourth are files that do get installed, the third is the .exe file that does not get installed. NOTE THE NULL ACTION ON THIS ENTRY.
Action start 8:04:41: InstallValidate.
MSI (s) (18:F4) [08:04:41:671]: Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _24A30964F6B6462282E161248AF15827; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _7B95B32E33EB4F699B44D53CA5BC22B5; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _2FBD153583AF40C09EB9920149F7C7B7; Installed: Absent; Request: Local; Action: Null
MSI (s) (18:F4) [08:04:41:671]: Component: _38A400D7DB76479CA0EC6D643D5793CD; Installed: Absent; Request: Local; Action: Local
If you look in the log at the line 603 you will find the following:
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {ADC6C3E9-A0CF-4AFC-9998-7B9449C8EA10} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {F74907E7-607E-49D1-B613-D63A36ADB020} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {B1FE4023-E176-42BC-92C3-15B8E50CFBB0} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {E6F5DF5D-3460-4B44-8743-48787E68A2C1} since another client exists
This can happen if the same components are shared between multiple packages installed on the same machine. Windows Installer keeps a refcount for the components and does allow removing them until all the applications that use them are removed.
If you encounter this on your test/development machine I recommend testing on a clean VM, to ensure no other previous tests affect this one.
Also, if you know you have used the same components in packages for other applications please edit them, making sure each component has an unique GUID for each package.
A keyfile is used by Windows Installer to detect the component, along with its GUID, here are more details:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx
As you suspected, Windows Installer is also checking the file version, which I assumed you correctly incremented in the new version. Here are the rules followed by it:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
You need to have the version column from the File table for the EXE set to a higher value then of the one already existent on the machine, otherwise Windows Installer will decide its better to keep the old one, because it has a higher version.
For the sake of putting some closure to this item, here's what I've discovered and what I did to fix things.
1) I'm still fuzzy on the meaning of versioned/unversioned file. I guess all .exe files ar versioned. I suppose this means that such files need corresponding versions in the File table.
2) I now understand the file table version need have no connection to the ProductVersion.
3) I have been using illegal ProductVersion Eg. 2012.02.16. I switched to using something like 12.2.16.
4) I set the .exe VS_VERSION_INFO FILEVERSION in Visual Studio and added the same value to File table Version field.
Now, all files are replaced when I do a major upgrade.
The entries in the file table ALL have no version. Why are the non .exe files treated differently and reinstalled?
I suppose the other files have their version increased. Windows Installer should apply the versioning rules on all the files from the package.
So this means it's impossible for a user to install an older version of a product using a major upgrade msi?
I don't see a solution if you want to keep the version smaller in the new package. Except of course, custom actions.
And what constitutes a legal version? In one place I see 255.255.65535 and in another I see 65535.65535.65535.65535
Both of them are correct version numbers. The latter value is usually set to a file to make sure it replaces any other existing file from the machine, i.e. its the highest version number allowed by the OS.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).aspx
Hopefully I can explain this clearly:
I have a Visual Studio Setup Project (C++), my current build scripts do the following:
update the version numbers
update the PackageCode
update the ProductCode
This has worked without any problems in the past (approximately 20 releases).
I just did a new release where a custom action was removed (which was included in most of the previous releases). My build process was the same as above.
Now when I install I get a duplicate entry in Windows Add and Remove Programs.
ie:
previous version was 1.0.6.2 and is installed on the computer.
I then install new version 1.0.7.0 (has custom action removed)
Add and remove programs lists 1.0.6 and 1.0.7.
Any idea what I need to do to fix this? I expect what is happening is that the new version is causing the uninstaller for 1.0.6.2 to run, but is not getting it to remove the FeatureComponents that were removed as part of 1.0.7.0.
Is there a way to force their removal?
Make sure that both versions have the same installation type (per-user or per-machine). This is controlled through ALLUSERS installer property or InstalAllUsers setup project property.
Also, they should use the same UpgradeCode. You can check it in Property table by opening the MSI files with Orca.
If these conditions are met and the problem persists, try creating a verbose log and see what happens when FindRelatedProducts and RemoveExistingProducts actions are executed.