Hi
We would like to install multiple products that share a 'common core'. The 'common core' includes our drivers (one of which we'd like to install using DIFx, the others have a custom action to install them) as well as some executables. We would like the 'common core' to have its own entry in add/remove programs.
The 'common core' would be installed with the first product installed on a PC and reference counted as each new product that uses the 'common core' is installed. Each product could be unistalled, and the 'common core' should be uninstalled when the last product that is using it is uninstalled.
What is the best way to achieve this using AI?
I have so far tried this approach: I created an msi that installed the 'common core' components - I tested this and it installed and uninstalled fine. I then created two product msi's that used a custom action to install the 'common core' msi. I found the install of both products worked fine but uninstall has multiple issues. When I try and remove either of the products using add/remove programs they cannot uninstall because one of their components cannot be uninstalled (the 'common core' I assume) and when I try to remove the 'common core' using it's entry in add/remove programs it won't uninstall because it doesn't believe it is installed! I feel I am doing something wrong somewhere!
I hope this makes sense and thanks in advance for any help...
Sian
Suggested Articles
Further to this post, we have tried to use the AI MSI custom actions for nested MSI installations - with limited success.
The Core.msi contains a driver installed with DIFx. Core.msi installs and uninstalls fine stand alone. However, when Product1.msi references Core.msi (using the MSI Database custom actions) Core.msi falls over during the DIFx install phase. Inspecting the logs, it appears that DIFx cannot find or open the driver's inf file.
Are we missing something? Are there limitations on using DIFx, particularly from a nested install?
Many thanks in advance for any help!
David.
The Core.msi contains a driver installed with DIFx. Core.msi installs and uninstalls fine stand alone. However, when Product1.msi references Core.msi (using the MSI Database custom actions) Core.msi falls over during the DIFx install phase. Inspecting the logs, it appears that DIFx cannot find or open the driver's inf file.
Are we missing something? Are there limitations on using DIFx, particularly from a nested install?
Many thanks in advance for any help!
David.
-
davincicode
- Posts: 7
- Joined: Wed Apr 13, 2005 1:49 pm
Let me put forth the caveat that I am not an installer expert and decided that I did not want to mess around with custom 'features', sub-installers, etc. I tried a couple times and didn't have much luck with these advanced/complex features, so went for a solution that was very basic but worked in my situation.
The situation I had was "how do I install my 'shared' components" so that all my utilities (installed separately) could use them?
I ended up creating a separate installer for the shared components and then made the installation of these shared components a prerequisite for all the utility installers. For some utilities I bundled the prerequisite into the utility installer. For others, I provided a download link so the 'shared components' were automatically downloaded and installed. I did it two different ways because sometimes there is Internet access and other times there is not.
The upside of this approach was that it was simple, understandable, and reliable. You can install/uninstall utilities all day long and nothing gets screwed up.
The downside is that for a complete uninstall, the user must uninstall one additional 'program'. However, the shared components are labeled and the uninstall is simple and robust.
If someone wanted a truly automated solution then each utility installer could have incremented a reference count in the registry section for the shared components and each uninstall could have decremented the count. If the count dropped to zero, the utility uninstaller could call the uninstaller for the shared components. Rather than a simple count, one could also implement signature+count so increments/decrements are tallied by utility. I did not implement any sort of counting system because I asked my customers and they did not mind the one additional uninstall task and I strongly believe in "as simple as possible".
Anyhow, I am sure the installer gurus could tell you a better way
The situation I had was "how do I install my 'shared' components" so that all my utilities (installed separately) could use them?
I ended up creating a separate installer for the shared components and then made the installation of these shared components a prerequisite for all the utility installers. For some utilities I bundled the prerequisite into the utility installer. For others, I provided a download link so the 'shared components' were automatically downloaded and installed. I did it two different ways because sometimes there is Internet access and other times there is not.
The upside of this approach was that it was simple, understandable, and reliable. You can install/uninstall utilities all day long and nothing gets screwed up.
The downside is that for a complete uninstall, the user must uninstall one additional 'program'. However, the shared components are labeled and the uninstall is simple and robust.
If someone wanted a truly automated solution then each utility installer could have incremented a reference count in the registry section for the shared components and each uninstall could have decremented the count. If the count dropped to zero, the utility uninstaller could call the uninstaller for the shared components. Rather than a simple count, one could also implement signature+count so increments/decrements are tallied by utility. I did not implement any sort of counting system because I asked my customers and they did not mind the one additional uninstall task and I strongly believe in "as simple as possible".
Anyhow, I am sure the installer gurus could tell you a better way
FOLLOW US