Self Heal Separate Package
I'm new at this deployment stuff so please forgive me if this is a dumb question or has been covered in other threads, I have searched for similar questions but have found none yet. Perhaps I am not searching for the right terms.
I am looking for a solution to a problem with vendor supplied msi's. I have a package that is basically an add-on to several other packages and installs files into the directories of the applications that it is integrated with. If the other applications are installed first then there is no problem. The problem occurs when one of the applications that this software is integrated with is installed after the add-on package. In this situation we need to manually run a repair of the add-on package to get it to install the necessary files onto the newly installed application. I would like to automate the running of the repair for the add-on package.
I can think of two possible ways to do this:
1. Add a script to the msi for each of the packages that this product extends that checks for the presence of the add-on package and invokes msiexec to repair the add-on package. My concern with this approach is that the first msi would create a second instance of msiexec and would cause issues with GPO deployment.
2. Have the add-on package set registry keys for each of the products it is integrated with but are not installed at the time of its installation. When one of the main packages is installed it could check for the existence of its registry key and delete it. I could use the missing key to trigger a self heal of the add-on, but since this product is an add-on and does not have its own shortcut what would prompt the self heal?
I would appreciate any advice on either of these approaches or any other approaches for dealing with this issue.
Thanks in advance for any help.
Brett
I am looking for a solution to a problem with vendor supplied msi's. I have a package that is basically an add-on to several other packages and installs files into the directories of the applications that it is integrated with. If the other applications are installed first then there is no problem. The problem occurs when one of the applications that this software is integrated with is installed after the add-on package. In this situation we need to manually run a repair of the add-on package to get it to install the necessary files onto the newly installed application. I would like to automate the running of the repair for the add-on package.
I can think of two possible ways to do this:
1. Add a script to the msi for each of the packages that this product extends that checks for the presence of the add-on package and invokes msiexec to repair the add-on package. My concern with this approach is that the first msi would create a second instance of msiexec and would cause issues with GPO deployment.
2. Have the add-on package set registry keys for each of the products it is integrated with but are not installed at the time of its installation. When one of the main packages is installed it could check for the existence of its registry key and delete it. I could use the missing key to trigger a self heal of the add-on, but since this product is an add-on and does not have its own shortcut what would prompt the self heal?
I would appreciate any advice on either of these approaches or any other approaches for dealing with this issue.
Thanks in advance for any help.
Brett
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
Surely the best approach is to prevent installation of the add-in if the "host" application isn't installed?
You don't say what authoring tools you have at your disposal but the two major ones, Wise and InstallShield, make setting up what is commonly called a System Search relatively easy. If you're being ultra masochistic and using InstEdit/Orca, you need to be looking at the AppSearch table and related tables, CompLocator, RegLocator, IniLocator and DrLocator.
You can control the order of installation in GP by ordering the links, of course.
You don't say what authoring tools you have at your disposal but the two major ones, Wise and InstallShield, make setting up what is commonly called a System Search relatively easy. If you're being ultra masochistic and using InstEdit/Orca, you need to be looking at the AppSearch table and related tables, CompLocator, RegLocator, IniLocator and DrLocator.
You can control the order of installation in GP by ordering the links, of course.
Posted by:
bwagner
14 years ago
I am controling the order via Group Policy and the add-on already checks that at least one product that it extends is installed. The problem occurs when a user request an application be installed and the add-on and then a month later request that the a second program be installed that also requires the add-on. When I push the second program in order to get the add-on integrated with it I need to run a repair on the add-on. I am using Installshield 2011
Thanks,
Brett
Thanks,
Brett
Posted by:
pjgeutjens
14 years ago
Brett,
you could theoretically use one of the other mechanisms for triggering a repair than a shortcut. In this instance I'm thinking specifically of a dll registration (your addin has some, right?). Have a look at the Class table, libraries registered here will actually get some self-heal triggers written with their data in the registry (the so-called Darwin descriptors, or as I like to call em random junk strings).
You could perhaps make components in your addin that have a registry keyfile, one for each parent application, something like HKLM\Software\MyAddin\parentonereinstalled, and then have your parent apps delete them on installation and then rely on the class registration to trigger the self-healing on the missing registry keys...
I have to admit this is a rather theoretical idea, and putting it in practice will take some doing, but it might be an option for you...
PJ
you could theoretically use one of the other mechanisms for triggering a repair than a shortcut. In this instance I'm thinking specifically of a dll registration (your addin has some, right?). Have a look at the Class table, libraries registered here will actually get some self-heal triggers written with their data in the registry (the so-called Darwin descriptors, or as I like to call em random junk strings).
You could perhaps make components in your addin that have a registry keyfile, one for each parent application, something like HKLM\Software\MyAddin\parentonereinstalled, and then have your parent apps delete them on installation and then rely on the class registration to trigger the self-healing on the missing registry keys...
I have to admit this is a rather theoretical idea, and putting it in practice will take some doing, but it might be an option for you...
PJ
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.