We are in pre-sales mode and testing Advanced Installer.
We are looking to move away from InstallShield.
We have a previous version of our software installed in Industry using a InstallShield package.
We have successfully built a test install package that meets our needs 90% with Advanced Installer trial version.
What we cannot figure out how do to, and we were told we could do this, is to include the removal of the previous version of our software that was installed with the InstallShield package mentioned above.
We have created a new Product Code (as we always did with InstallShield).
We have edited the Upgrade Code using the previous upgrade code from the last InstallShield install package (we NEVER change the upgrade code before in our InstallShield...only Product Code and Package Code).
In Upgrades, we set "Automatically upgrade older product versions" AND "uninstall old version first and then install new version"
Nothing else was done in Upgrades.
Yet, when installing it creates another version and does not remove the old version.
We must be missing a step. We are basically in emergency mode at this time. If we can solve this, we will be purchasing.
Certainly time matters to us and will help with a decision.
Suggested Articles
Re: Uninstalling previous Installshield install
I'd like to add one more bit of information on our issue.
During the install, the older files are definitely being replaced.
However, in the control panel/remove programs, there are two entries: one for the old version and one for the new version.
In addition, there are two application icons on the desktop.
During the install, the older files are definitely being replaced.
However, in the control panel/remove programs, there are two entries: one for the old version and one for the new version.
In addition, there are two application icons on the desktop.
Re: Uninstalling previous Installshield install
Hello and welcome to our forums,
I think this could happen (the old version control panel entry being preserved) if the related CP entry removal operation is handled only by a InstallShield proprietary action. This should be usually handled by an uninstaller.exe (or similar) module included and delivered by your old product version.
As a workaround you could try to implement in the current setup project (built with Advanced Installer) a custom action which launches the old product uninstaller.exe to completely uninstall it.
Let us know if this helped.
All the best,
Daniel
I think this could happen (the old version control panel entry being preserved) if the related CP entry removal operation is handled only by a InstallShield proprietary action. This should be usually handled by an uninstaller.exe (or similar) module included and delivered by your old product version.
As a workaround you could try to implement in the current setup project (built with Advanced Installer) a custom action which launches the old product uninstaller.exe to completely uninstall it.
Let us know if this helped.
All the best,
Daniel
Re: Uninstalling previous Installshield install
Writing an update to this - yes one year later.
A year ago we wanted to move from InstallShield to Advanced Installer.
Prerequisite was that Advanced Installer could un-install a current version of our software that used an InstallShield package - then install a new version of our application. Such that there would only be one Control Panel entry (the latest version) and one Registry entry (the latest version).
We could never get this to work a year ago even with support.
Here we are one year later. We waited because we needed to find the right time (in terms of our application) to once again try and move to Advanced Installer. We were also hoping that Advanced Installer maybe got better and could handle this in an easy process.
The Prerequisite is the same.
We need to new Advanced Installer package to first un-install the existing version which used an InstallShield package - and then follow up installing a new version.
I'm writing to unfortunately say - even with support we still cannot get this to work.
Every time, no matter what we use (Upgrades, Custom Actions using several different parameters, etc...) the results are two versions of our software remaining in the Control Panel and in the Registry.
We would like to move to Advanced Installer. At this point it has been suggestions to "try this" or "try that" which has been labor intensive and frustrating.
We would like for Advanced Installer to actually work thru this internally with 100% success, prove it with examples with our InstallShield data which has been provided. Feed back from users and Advanced Installer is very welcomed as we really want to move away from InstallShield if possible.
A year ago we wanted to move from InstallShield to Advanced Installer.
Prerequisite was that Advanced Installer could un-install a current version of our software that used an InstallShield package - then install a new version of our application. Such that there would only be one Control Panel entry (the latest version) and one Registry entry (the latest version).
We could never get this to work a year ago even with support.
Here we are one year later. We waited because we needed to find the right time (in terms of our application) to once again try and move to Advanced Installer. We were also hoping that Advanced Installer maybe got better and could handle this in an easy process.
The Prerequisite is the same.
We need to new Advanced Installer package to first un-install the existing version which used an InstallShield package - and then follow up installing a new version.
I'm writing to unfortunately say - even with support we still cannot get this to work.
Every time, no matter what we use (Upgrades, Custom Actions using several different parameters, etc...) the results are two versions of our software remaining in the Control Panel and in the Registry.
We would like to move to Advanced Installer. At this point it has been suggestions to "try this" or "try that" which has been labor intensive and frustrating.
We would like for Advanced Installer to actually work thru this internally with 100% success, prove it with examples with our InstallShield data which has been provided. Feed back from users and Advanced Installer is very welcomed as we really want to move away from InstallShield if possible.
Re: Uninstalling previous Installshield install
Hello and welcome back to our forums,
I have read the conversation between you and my colleague Daniel from 1 year ago.
From what I understand, you are not performing an upgrade at all. The files are indeed replaced because the newer MSI is installed on top of the old one.
We have run a small test scenario and I could notice the following:
The case is as it follows:
- basic project created in InstallShield which contains only few files for test purposes
- basic project created in Advanced Installer which should upgrade the earlier created MSI
By doing the above, I could notice, in the "Upgrade" table, the following:
- VersionMAX, Language and the 517 attribute.
The 517 attribute is made up of the following:
- 512 - which detects the range of versions including the value in VersionMax.
+
- 4 - which continues installation upon failure to remove a product or application.
+
- 1 - which is about the "MigrateFeaturesState" action (less relevant in our case)
With that being said, one problem could be the fact that your setup does not correctly detect the version. My advice, in this case, would be to:
1. set the VersionMIN to the lowest version of your MSI
2. set the VersionMAX to the highest version of your MSI (the latest version of your MSI)
In "Upgrade" table, the attribute value should be 512+256=768, where:
256 - means that the setup will detect the range of versions including the value in VersionMin.
Another case I can think of would consist of the fact that one of your MSI is set to install per-user and the other one is set to install per-machine. This can be checked first hand (in Advanced Installer) by going to "Install Parameters" page --> "Installation type". Otherwise, this can be checked through the "ALLUSERS" property.
Other than that, I am afraid that I can think of any other reason of why this would happen.
However, if possible, I would like to further investigate this. In order to do so, I may need the following resources:
- the older version of your MSI (the one created with InstallShield)
- the newer version of your MSI (the one created with Advanced Installer)
- the .AIP (Advanced Installer Project) file that was used to build the second MSI
You can send me the download link for the two MSIs and the .AIP file by e-mail at support at advancedinstaller dot com.
Looking forward to hearing from you.
Best regards,
Catalin
I have read the conversation between you and my colleague Daniel from 1 year ago.
From what I understand, you are not performing an upgrade at all. The files are indeed replaced because the newer MSI is installed on top of the old one.
We have run a small test scenario and I could notice the following:
The case is as it follows:
- basic project created in InstallShield which contains only few files for test purposes
- basic project created in Advanced Installer which should upgrade the earlier created MSI
By doing the above, I could notice, in the "Upgrade" table, the following:
- VersionMAX, Language and the 517 attribute.
The 517 attribute is made up of the following:
- 512 - which detects the range of versions including the value in VersionMax.
+
- 4 - which continues installation upon failure to remove a product or application.
+
- 1 - which is about the "MigrateFeaturesState" action (less relevant in our case)
With that being said, one problem could be the fact that your setup does not correctly detect the version. My advice, in this case, would be to:
1. set the VersionMIN to the lowest version of your MSI
2. set the VersionMAX to the highest version of your MSI (the latest version of your MSI)
In "Upgrade" table, the attribute value should be 512+256=768, where:
256 - means that the setup will detect the range of versions including the value in VersionMin.
Another case I can think of would consist of the fact that one of your MSI is set to install per-user and the other one is set to install per-machine. This can be checked first hand (in Advanced Installer) by going to "Install Parameters" page --> "Installation type". Otherwise, this can be checked through the "ALLUSERS" property.
Other than that, I am afraid that I can think of any other reason of why this would happen.
However, if possible, I would like to further investigate this. In order to do so, I may need the following resources:
- the older version of your MSI (the one created with InstallShield)
- the newer version of your MSI (the one created with Advanced Installer)
- the .AIP (Advanced Installer Project) file that was used to build the second MSI
You can send me the download link for the two MSIs and the .AIP file by e-mail at support at advancedinstaller dot com.
Looking forward to hearing from you.
Best regards,
Catalin
Re: Uninstalling previous Installshield install
Hi,
Thank you for this feedback.
In this case, the Installshield and Advanced Installer packages were both USER and not Machine.
"Upgrade" - means we are going from version 3.1.0.0 to version 3.1.1.0 with our application.
Note: Our Installshield package we have used for 6+ years - always removes the entire previous install - and then installs the new, latest, version of our software. Based on experiences, this has been best for us.
We would like to continue the process of completely removing the existing installation and then installing the new version once the existing installation has been removed. Installshield has handled this perfectly for us thus far.
Our Min Version in both packages is empty.
Our Max Version in both packages is v3.1.0.0
Our Installshield package, for the v3.1.1.0 package, during our testing completely removed v3.1.0.0 and then installed v3.1.1.0 as expected using these settings. The Advanced Installer, using these settings did not remove the existing installation. It did add the new version creating two installs.
We were advised to create a Custom Action, that references an Upgrade Condition.
The Upgrade Page included the Upgrade Code from our Installshield msi. The condition was called "OLDVERSION_DETECTED"
The custom action referenced this condition.
The custom action included this file to launch setting: [ProgramFilesFolder]InstallShield Installation Information\{3B741429-5E2F-4EEF-9ECC-B1007A60D350}\setup.exe
This GUID is the v3.1.0.0 InstallShield msi Product ID and was indeed found on the target machine in the indicated directory.
The custom action parameters we were advised to use were: -x -s -f1[&setup.iss]
The setup.iss file was added as a temporary file.
This all seemed logical to us.
Note: we were advised to first try this via the cmd line as a test. When running on the cmd line, using the -s parameter, nothing happened.
The setup.log indicated ResultCode=-3
We googled and after a long time found some info - which recommended removing the -s parameter.
We did, and then the cmd line executed successfully - however it prompted for "Modify, Repair or Remove" which we did not want for our users.
So, we removed the -s and added the parameter -removeonly....again doing a lot of googling.
The result was not a "Modify, Repair or Removal" dialog - but it did have a "are you sure you want to fully remove....etc...." dialog.
We did not like this, but made a decision with some communication to our users to answer "Yes", we could live with this.
Bottom line in this long note is never a "silent un-install" was experienced.
So - we then continued to complete the Advanced Installer package with this Custom Action recommended but with these parameters: -x -removeonly -f1[&setup.iss]
As Advised, we put the custom action in the Windows Dialog stage, right after "Paths Resolution"
During out testing - nothing happened. When I say "Nothing Happened" - I mean it did not appear as though Advanced Installer ever executed the custom action. We expected at least one dialog - based on our cmd line testing.
The result was two version of our software in the Control Panel and in the Registry.
We were advised to use this parameter: -uninst
Bottom line, nothing happened. Again, it does not appear as though Advanced Installer is even executing the custom action. During the testing there is no lag time at all when executing the .exe install and seeing Advanced Installer install dialogs. It if is indeed executing the custom action PRIOR to the new install, even if it were silent, there would be some lag time....but none.
Our experience is that no matter what we have been advised to try related to the custom action and any changed parameters - the Advanced Installer package is never executing the custom action. Period.
We have provided all the files requested during this time: The v3.1.0.0 Installshield msi, the setup.iss and the v3.1.1.0 Advanced Installer.msi to the email you provided. However as requested - We have resent a new invite email to the support at advanced installer dot com email - to our share file site.
Our request - is that rather than sending emails to try this and try that - is that Advanced Installer work thru this internally and then when a 100% successful solution has been completed - then advise us on what we are doing wrong.
We look forward to hearing from you.
Thank you for this feedback.
In this case, the Installshield and Advanced Installer packages were both USER and not Machine.
"Upgrade" - means we are going from version 3.1.0.0 to version 3.1.1.0 with our application.
Note: Our Installshield package we have used for 6+ years - always removes the entire previous install - and then installs the new, latest, version of our software. Based on experiences, this has been best for us.
We would like to continue the process of completely removing the existing installation and then installing the new version once the existing installation has been removed. Installshield has handled this perfectly for us thus far.
Our Min Version in both packages is empty.
Our Max Version in both packages is v3.1.0.0
Our Installshield package, for the v3.1.1.0 package, during our testing completely removed v3.1.0.0 and then installed v3.1.1.0 as expected using these settings. The Advanced Installer, using these settings did not remove the existing installation. It did add the new version creating two installs.
We were advised to create a Custom Action, that references an Upgrade Condition.
The Upgrade Page included the Upgrade Code from our Installshield msi. The condition was called "OLDVERSION_DETECTED"
The custom action referenced this condition.
The custom action included this file to launch setting: [ProgramFilesFolder]InstallShield Installation Information\{3B741429-5E2F-4EEF-9ECC-B1007A60D350}\setup.exe
This GUID is the v3.1.0.0 InstallShield msi Product ID and was indeed found on the target machine in the indicated directory.
The custom action parameters we were advised to use were: -x -s -f1[&setup.iss]
The setup.iss file was added as a temporary file.
This all seemed logical to us.
Note: we were advised to first try this via the cmd line as a test. When running on the cmd line, using the -s parameter, nothing happened.
The setup.log indicated ResultCode=-3
We googled and after a long time found some info - which recommended removing the -s parameter.
We did, and then the cmd line executed successfully - however it prompted for "Modify, Repair or Remove" which we did not want for our users.
So, we removed the -s and added the parameter -removeonly....again doing a lot of googling.
The result was not a "Modify, Repair or Removal" dialog - but it did have a "are you sure you want to fully remove....etc...." dialog.
We did not like this, but made a decision with some communication to our users to answer "Yes", we could live with this.
Bottom line in this long note is never a "silent un-install" was experienced.
So - we then continued to complete the Advanced Installer package with this Custom Action recommended but with these parameters: -x -removeonly -f1[&setup.iss]
As Advised, we put the custom action in the Windows Dialog stage, right after "Paths Resolution"
During out testing - nothing happened. When I say "Nothing Happened" - I mean it did not appear as though Advanced Installer ever executed the custom action. We expected at least one dialog - based on our cmd line testing.
The result was two version of our software in the Control Panel and in the Registry.
We were advised to use this parameter: -uninst
Bottom line, nothing happened. Again, it does not appear as though Advanced Installer is even executing the custom action. During the testing there is no lag time at all when executing the .exe install and seeing Advanced Installer install dialogs. It if is indeed executing the custom action PRIOR to the new install, even if it were silent, there would be some lag time....but none.
Our experience is that no matter what we have been advised to try related to the custom action and any changed parameters - the Advanced Installer package is never executing the custom action. Period.
We have provided all the files requested during this time: The v3.1.0.0 Installshield msi, the setup.iss and the v3.1.1.0 Advanced Installer.msi to the email you provided. However as requested - We have resent a new invite email to the support at advanced installer dot com email - to our share file site.
Our request - is that rather than sending emails to try this and try that - is that Advanced Installer work thru this internally and then when a 100% successful solution has been completed - then advise us on what we are doing wrong.
We look forward to hearing from you.
Re: Uninstalling previous Installshield install
I should mention, as I realize I did not, that we did indeed enter the Upgrade Code from our installshield v3.1.0.0 package in the Upgrades Page and have verified this multiple times since it was suggested to us that "we must not be putting in the correct Upgrade Code"
This same code used in Advanced Installer is also used in the InstallShield package.
And, as mentioned during our testing of going from v3.1.0.0 to v3.1.1.0 using an InstallShield test package - the existing install is first removed successfully per our wishes.
This same code used in Advanced Installer is also used in the InstallShield package.
And, as mentioned during our testing of going from v3.1.0.0 to v3.1.1.0 using an InstallShield test package - the existing install is first removed successfully per our wishes.
Re: Uninstalling previous Installshield install
Hello,
We were just wondering if there is any status on this issue?
We are one week late on our recent version release date.
If there does not appear to be a solution, then we can revert back to InstallShield.
Please Advise.
Thank you
We were just wondering if there is any status on this issue?
We are one week late on our recent version release date.
If there does not appear to be a solution, then we can revert back to InstallShield.
Please Advise.
Thank you
Re: Uninstalling previous Installshield install
Hello,
Thanks for the provided files.
I have further investigated them and I could notice the following:
The upgrade behavior ("Upgrades" page --> under "Upgrades" section --> double click on the "UpgradeCode" --> "Upgrade Action" tab) is set to "Detect only, placing results in property.".
If you want the files to be removed, you should check the "Find and remove products" option.
Hope this helps.
Best regards,
Catalin
Thanks for the provided files.
I have further investigated them and I could notice the following:
- DetectOnly.PNG (11.98 KiB) Viewed 20936 times
If you want the files to be removed, you should check the "Find and remove products" option.
Hope this helps.
Best regards,
Catalin
Re: Uninstalling previous Installshield install
Also, after further investing this a bit more, I could notice that in the MSI that was created using InstallShield, the ALLUSERS property is equal to 1, which means a per-machine installation was performed.
Meanwhile, in the .AIP file, the installation type is "Per-user only (with administrator rights required", which means that the ALLUSERS property will be equal to 0.
Previously, you have stated that:
Please keep in mind that a per-user installation can not upgrade a per-machine installation and vice-versa.
Best regards,
Catalin
Meanwhile, in the .AIP file, the installation type is "Per-user only (with administrator rights required", which means that the ALLUSERS property will be equal to 0.
Previously, you have stated that:
which doesn't seem to be true.In this case, the Installshield and Advanced Installer packages were both USER and not Machine.
Please keep in mind that a per-user installation can not upgrade a per-machine installation and vice-versa.
Best regards,
Catalin
Re: Uninstalling previous Installshield install
Hi,
Thank you for this information.
We do want the files to be removed so we will check that option.
We will also try and change the .aip to a Machine install and we will report back the results.
Thank you
Thank you for this information.
We do want the files to be removed so we will check that option.
We will also try and change the .aip to a Machine install and we will report back the results.
Thank you
Re: Uninstalling previous Installshield install
Hi Catalin,
Wanted to provide some status on this issue.
1. So it would appear that the main issue was the per User vs per Machine selection in the Advanced Installer project. Once this was changed to the per Machine in the Advanced Installer project - then when we tested - the previous InstallShield installation was first un-installed and then the new version from the Advanced Installer package was installed. So thank you for that piece of information.
2. In the Edit Upgrade screen shot you provided - the screen shot indicated you were on the Upgrade Action tab....we could never get there. It opens in the Product Info tab...and then will not let us select the Upgrade Action tab...however based on number 1 above it appears that this is not an issue anyway.
3. We cannot get a "Silent Uninstall" at all. We added the following in our custom action parameter:
-x -s -f1[&setup.iss]
using these parameters during our testing resulted in a failed installation right at the beginning. We checked to make sure the setup.iss file was included and it is in our Temporary folder. So to continue our testing just to get the Advanced Installer package to work we changed the custom action parameters to:
-x -removeonly -f1[&setup.iss]
and this worked - however it prompted us with a "are you sure you want to completely uninstall".....answering YES continued with the initial uninstall of the InstallShield package version going thru the InstallShield dialogs...then had to click "Finish" then came the Advanced Installer install Dialog where we had to click "Install".....while this worked overall....this is very confusing.
Does Advanced Installer have some ideas on how we can get the Silent Uninstall to work?
If we could get the Silent Uninstall to work, then I think we would finally be able to move forward using Advanced Installer.
Please advise.
Thank you
Wanted to provide some status on this issue.
1. So it would appear that the main issue was the per User vs per Machine selection in the Advanced Installer project. Once this was changed to the per Machine in the Advanced Installer project - then when we tested - the previous InstallShield installation was first un-installed and then the new version from the Advanced Installer package was installed. So thank you for that piece of information.
2. In the Edit Upgrade screen shot you provided - the screen shot indicated you were on the Upgrade Action tab....we could never get there. It opens in the Product Info tab...and then will not let us select the Upgrade Action tab...however based on number 1 above it appears that this is not an issue anyway.
3. We cannot get a "Silent Uninstall" at all. We added the following in our custom action parameter:
-x -s -f1[&setup.iss]
using these parameters during our testing resulted in a failed installation right at the beginning. We checked to make sure the setup.iss file was included and it is in our Temporary folder. So to continue our testing just to get the Advanced Installer package to work we changed the custom action parameters to:
-x -removeonly -f1[&setup.iss]
and this worked - however it prompted us with a "are you sure you want to completely uninstall".....answering YES continued with the initial uninstall of the InstallShield package version going thru the InstallShield dialogs...then had to click "Finish" then came the Advanced Installer install Dialog where we had to click "Install".....while this worked overall....this is very confusing.
Does Advanced Installer have some ideas on how we can get the Silent Uninstall to work?
If we could get the Silent Uninstall to work, then I think we would finally be able to move forward using Advanced Installer.
Please advise.
Thank you
Re: Uninstalling previous Installshield install
Hello Michael,
Please accept my apologies for the delayed reply.
Thank you for your followup on this.
I have had another look over your project and I could notice the fact your are building a .EXE project.
A workaround to the above issue could be the following: you can create a new project which will only contain your custom action. Additionally, you can disable the "Register product with Windows Installer" option from "Product Details" page --> "Add or Remove Programs (Control Panel)" (so the program will not appear in Control Panel -- the reason can be seen below).
After doing so, you can then build this setup and add it as a "Pre-Install" prerequisite in your main setup. This way, the installation should proceed as it follows:
- since the pre-install prerequisites are handled by our EXE bootstrapper, it should not interfere with the main installation (this way, we can avoid the Windows Installer limitation). This "prerequisite" will uninstall the previous version.
- after the above step is completed, the installation of your main setup should take place
Hope this helps.
Best regards,
Catalin
Please accept my apologies for the delayed reply.
Thank you for your followup on this.
You are always welcome. I'm glad I could help.1. So it would appear that the main issue was the per User vs per Machine selection in the Advanced Installer project. Once this was changed to the per Machine in the Advanced Installer project - then when we tested - the previous InstallShield installation was first un-installed and then the new version from the Advanced Installer package was installed. So thank you for that piece of information.
This is strange. However, you are right, this does not seem to be an issue anymore.2. In the Edit Upgrade screen shot you provided - the screen shot indicated you were on the Upgrade Action tab....we could never get there. It opens in the Product Info tab...and then will not let us select the Upgrade Action tab...however based on number 1 above it appears that this is not an issue anyway.
This might happen due to the fact that your custom action is executing during the "Install Execution Stage" - on deferred. This is a known Windows Installer limitation which does not allow two installation processes to take place at the same time.3. We cannot get a "Silent Uninstall" at all. We added the following in our custom action parameter:
I have had another look over your project and I could notice the fact your are building a .EXE project.
A workaround to the above issue could be the following: you can create a new project which will only contain your custom action. Additionally, you can disable the "Register product with Windows Installer" option from "Product Details" page --> "Add or Remove Programs (Control Panel)" (so the program will not appear in Control Panel -- the reason can be seen below).
After doing so, you can then build this setup and add it as a "Pre-Install" prerequisite in your main setup. This way, the installation should proceed as it follows:
- since the pre-install prerequisites are handled by our EXE bootstrapper, it should not interfere with the main installation (this way, we can avoid the Windows Installer limitation). This "prerequisite" will uninstall the previous version.
- after the above step is completed, the installation of your main setup should take place
Hope this helps.
Best regards,
Catalin