This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: MSI Project Package Code Question
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2011
12:40 PM
MSI Project Package Code Question
I am playing around with an MSI project installation. In my project I noticed that if I dont change the Package Code and the other properties (Version info and Product Code) and run my installation the installer would detect that I have already installed this verion of the application and it would ask me if I wanted to remove the application or repair it. OK I get that because it thinks the MSI is the same.
Now my question for clarification is that in my test builds (same files and dlls) if I generate a new package code each time a new build is launched and I run the installation it does not detect the previous installed version of the application. The previous version of the installation is same except for the different package code. So now when I install the newer build it does not ask me to uninstall the previous version of the application. It just installs over the existing one. Is this normal? What happens to the previous version of the application? Is it still on the computer when I go and uninstall my applicaton?
Thanks for any help...
Now my question for clarification is that in my test builds (same files and dlls) if I generate a new package code each time a new build is launched and I run the installation it does not detect the previous installed version of the application. The previous version of the installation is same except for the different package code. So now when I install the newer build it does not ask me to uninstall the previous version of the application. It just installs over the existing one. Is this normal? What happens to the previous version of the application? Is it still on the computer when I go and uninstall my applicaton?
Thanks for any help...
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 30, 2011
01:56 AM
You should configure your install for the Upgrade and Downgrade scenarios. That is the only way to make your installation detect old or new versions.
Now why is package GUID important?
It is because when you install an app for the first time, the msi database is cached on the local system. Be aware that Windows Installer engine, when invoked, always checks for the package guid in the registry. So, when you run the install for the second time, it checks the registry and finds the GUID and launches a repair.
In case you change the GUID, and do not configure your package for upgrade and downgrade scenario, your package is simply installed.
Go through these:
http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/PreventingDowngrades.htm
http://msdn.microsoft.com/en-us/library/aa372379(v=vs.85).aspx
The Upgrade Table can be configured in Direct Editor if you are advanced enough or you can use the Upgrades view UI .
Now why is package GUID important?
It is because when you install an app for the first time, the msi database is cached on the local system. Be aware that Windows Installer engine, when invoked, always checks for the package guid in the registry. So, when you run the install for the second time, it checks the registry and finds the GUID and launches a repair.
In case you change the GUID, and do not configure your package for upgrade and downgrade scenario, your package is simply installed.
Go through these:
http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/PreventingDowngrades.htm
http://msdn.microsoft.com/en-us/library/aa372379(v=vs.85).aspx
The Upgrade Table can be configured in Direct Editor if you are advanced enough or you can use the Upgrades view UI .
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 02, 2011
04:48 PM
Thanks for the info MSIYER.
Can you help clarify something for me in regards to minor upgrade. When you create an installation that targets earlier versions to perform a minor upgrade what happens to the MSI installer package and its info for that previous version? Does that information get cleared out of the registry when the minor upgrade has taken place? Or does it get removed when the application finally gets uninstalled? How does one prevent the package code GUIDS from cluttering the registry?
Can you help clarify something for me in regards to minor upgrade. When you create an installation that targets earlier versions to perform a minor upgrade what happens to the MSI installer package and its info for that previous version? Does that information get cleared out of the registry when the minor upgrade has taken place? Or does it get removed when the application finally gets uninstalled? How does one prevent the package code GUIDS from cluttering the registry?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 13, 2011
02:39 AM
When you create a minor upgrade package, it is in effect a new package. The package GUID will have to be different. But the Product GUID remains same. Also, the upgrade GUID is untouched.
Now the full details are:
You create a package for Version 1.0.0 of application ABC.It has a package GUID, say,{21EC2020-3AEA-1069-A2DD-08002B30309D}.
Clients install it on their machines. The msi is cached on the system in a hidden folderWindows\Installer.
If clients run the same package again, repair or maintenance of the installed software is triggered. The identity of the package is the GUID. Windows Installer checks for the GUID and the cached package in the hidden folder.
Now you package a minor upgrade of your app ABC. Its version is 1.1.0.
The package must have a different GUID to distinguish it from a package meant for version 1.0.0. Otherwise the maintenance install of version 1.0.0 will be triggered when 1.1.0 package is being invoked. Once the patching is done the the 1.0.0 version is transformed to 1.1.0 and the package GUID is also updated. Patching turns version 1.0.0 to 1.1.0. Invoking a 1.1.0 package on this machine will now trigger the repair.
Taking the above example forward, 1.0.0 version msi file was cached on the system. The patch for version 1.1.0 contains transforms that are applied to the 1.0.0 msi file at run time. This is the first step performed by the Windows Installer engine. The installation now proceeds in the repair or maintenance mode. This is because Patching is considered to be a repair. But the msi being used in the repair will be 1.1.0. Reinstallation of the product happens according the REINSTALLMODE parameters passed. This transformation of the 1.0.0 msi to 1.1.0 msi persists in case of non-uninstallable patches. The only way to remove the patch is to uninstall the application and install the base version.
As a setup developer, one need not worry about things cluttering up in the system. Windows Installer is smart enough to keep only the required info.
There are other important things like uninstallable and non-uninstallable patches.
Also got through these:
http://blogs.msdn.com/b/heaths/archive/2005/09/12/464047.aspx
http://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx
Now the full details are:
You create a package for Version 1.0.0 of application ABC.It has a package GUID, say,{21EC2020-3AEA-1069-A2DD-08002B30309D}.
Clients install it on their machines. The msi is cached on the system in a hidden folder
If clients run the same package again, repair or maintenance of the installed software is triggered. The identity of the package is the GUID. Windows Installer checks for the GUID and the cached package in the hidden folder.
Now you package a minor upgrade of your app ABC. Its version is 1.1.0.
The package must have a different GUID to distinguish it from a package meant for version 1.0.0. Otherwise the maintenance install of version 1.0.0 will be triggered when 1.1.0 package is being invoked. Once the patching is done the the 1.0.0 version is transformed to 1.1.0 and the package GUID is also updated. Patching turns version 1.0.0 to 1.1.0. Invoking a 1.1.0 package on this machine will now trigger the repair.
Taking the above example forward, 1.0.0 version msi file was cached on the system. The patch for version 1.1.0 contains transforms that are applied to the 1.0.0 msi file at run time. This is the first step performed by the Windows Installer engine. The installation now proceeds in the repair or maintenance mode. This is because Patching is considered to be a repair. But the msi being used in the repair will be 1.1.0. Reinstallation of the product happens according the REINSTALLMODE parameters passed. This transformation of the 1.0.0 msi to 1.1.0 msi persists in case of non-uninstallable patches. The only way to remove the patch is to uninstall the application and install the base version.
As a setup developer, one need not worry about things cluttering up in the system. Windows Installer is smart enough to keep only the required info.
There are other important things like uninstallable and non-uninstallable patches.
Also got through these:
http://blogs.msdn.com/b/heaths/archive/2005/09/12/464047.aspx
http://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 16, 2011
12:19 PM
MSIYER,
Thanks for the information. Thats the info I was looking for!!!
Mike
Thanks for the information. Thats the info I was looking for!!!
Mike