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
- :
- InstallAnywhere
- :
- InstallAnywhere Forum
- :
- Re: Maintenance Mode Confusion
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Oct 20, 2010
10:51 AM
Maintenance Mode Confusion
Hi friends,
I've been developing installers for about 10 years now, using InstallShield and InstallAnywhere. I was very pleased to see the new Maintenance Mode support added to IA2010. Great addition.
I hope I can explain this problem in a somewhat coherent fashion, I apologize in advance if this is confusing....
How is the maintenance mode supposed to work with existing instances of my software on an end-users system, when the previous version was installed using a different tool (InstallShield in this case)?
When I run the IA2010 build (first time we've used IA for this product line), then maintenance mode is not triggered, as far as the installer logic is concerned, there are no instances of the product on the system. This is understandable, I understand how the InstallAnywhere registry works to provide this information, and obviously, my older installations are not registered there.
So I could write my own detection and migration logic - this isn't a big deal, we've been doing this in our own home-grown maintenance mode for years. But I want to harness the built-in capabilities the IA2010 provides, and not have to rely on home-grown solutions for performing complex upgrades.
I guess my question is - how do I best handle this situation?
Worse --- if they actually perform a new installation of our software using the IA2010 installer, they will now in effect have two instances of the software on the system ---- this is fine, we support that capability.
However, there is no way to even identify that older instance of the product now, because the IA2010 installer now runs in Maintenance Mode, only recognizing the new instance of the software.
There is no clear way to indicate to our users that we can detect and upgrade that older instance of the software. They are left with the "Install New Instance" or "Modify Existing Instance" choice, and their other existing instance isn't listed. The user doesn't care or even know that we've switch installation tools, they just expect it to work. So either they cancel the setup and call our support department, or we have to put some notes in our docs that they actually have to select "Install New", then the setup will find the old instance and ask them if they want to upgrade it. This is probably not an acceptable solution.
Is there a Java API to artificially register an older installation into the InstallAnywhere registry? When my setup is run for the first time on a system, I could use my exisitng custom old version detection methods to find the old instance, but then somehow register it with the zerog registry so that when I run the IA2010 installer in maintenance mode again, it actually can perform a true maintenance operation on it? Meaning -- it will actually be listed in the "Modify Existing Instance" listing?
Oh - and for the purposes of the IA2010 maintenance mode, we're extending the Repair feature to act as an upgrade.
Any suggestions? I hope that you understand what I'm asking here. I realize that IA can't bend to the will of every user, and the maintenance mode is a great start, but I think I've found a sorta paradox in the implementation here. Thanks for any help.
I've been developing installers for about 10 years now, using InstallShield and InstallAnywhere. I was very pleased to see the new Maintenance Mode support added to IA2010. Great addition.
I hope I can explain this problem in a somewhat coherent fashion, I apologize in advance if this is confusing....
How is the maintenance mode supposed to work with existing instances of my software on an end-users system, when the previous version was installed using a different tool (InstallShield in this case)?
When I run the IA2010 build (first time we've used IA for this product line), then maintenance mode is not triggered, as far as the installer logic is concerned, there are no instances of the product on the system. This is understandable, I understand how the InstallAnywhere registry works to provide this information, and obviously, my older installations are not registered there.
So I could write my own detection and migration logic - this isn't a big deal, we've been doing this in our own home-grown maintenance mode for years. But I want to harness the built-in capabilities the IA2010 provides, and not have to rely on home-grown solutions for performing complex upgrades.
I guess my question is - how do I best handle this situation?
Worse --- if they actually perform a new installation of our software using the IA2010 installer, they will now in effect have two instances of the software on the system ---- this is fine, we support that capability.
However, there is no way to even identify that older instance of the product now, because the IA2010 installer now runs in Maintenance Mode, only recognizing the new instance of the software.
There is no clear way to indicate to our users that we can detect and upgrade that older instance of the software. They are left with the "Install New Instance" or "Modify Existing Instance" choice, and their other existing instance isn't listed. The user doesn't care or even know that we've switch installation tools, they just expect it to work. So either they cancel the setup and call our support department, or we have to put some notes in our docs that they actually have to select "Install New", then the setup will find the old instance and ask them if they want to upgrade it. This is probably not an acceptable solution.
Is there a Java API to artificially register an older installation into the InstallAnywhere registry? When my setup is run for the first time on a system, I could use my exisitng custom old version detection methods to find the old instance, but then somehow register it with the zerog registry so that when I run the IA2010 installer in maintenance mode again, it actually can perform a true maintenance operation on it? Meaning -- it will actually be listed in the "Modify Existing Instance" listing?
Oh - and for the purposes of the IA2010 maintenance mode, we're extending the Repair feature to act as an upgrade.
Any suggestions? I hope that you understand what I'm asking here. I realize that IA can't bend to the will of every user, and the maintenance mode is a great start, but I think I've found a sorta paradox in the implementation here. Thanks for any help.
(3) Replies
‎Oct 21, 2010
12:41 AM
For me it is clear that the Maintenance Mode is supposed to work only for software that has been previously installed with IA... and I think only with IA 2010, as this is the first version where this feature was introduced. I don't think you could use InstallShield in order to do a maintenance on a software that was installed with Wise or something else, could you?
‎Oct 21, 2010
09:53 AM
Thanks for the reply.
I completely agree and understand - I was more hoping that there was an API to artificially add other instances to the zerog registry file.
At any rate...we decided to ditch the maintenance mode and do our own custom method.
I completely agree and understand - I was more hoping that there was an API to artificially add other instances to the zerog registry file.
At any rate...we decided to ditch the maintenance mode and do our own custom method.
‎Dec 13, 2010
11:44 AM
I have a similar problem/question.
We have released a version of our software using IA that only allowed uninstall in Maintenance Mode. We now want to release a version that will allow upgrades and thought that using the "Repair Installation" could do this. But since the original version had uninstall only, the user will be forced to uninstall this one time. This is not a huge deal because we've created configuration files in our custom code that aren't removed by the uninstall process. We can detect these files and use the information from them.
But I was wondering if there was any way to allow a repair installation in this situation?
We have released a version of our software using IA that only allowed uninstall in Maintenance Mode. We now want to release a version that will allow upgrades and thought that using the "Repair Installation" could do this. But since the original version had uninstall only, the user will be forced to uninstall this one time. This is not a huge deal because we've created configuration files in our custom code that aren't removed by the uninstall process. We can detect these files and use the information from them.
But I was wondering if there was any way to allow a repair installation in this situation?
