Archive: Uninst on what you inst'd


Uninst on what you inst'd
  OK, looking for a little strategy advice. I've run into something new to me. Most client side app's deal with this, but I mostly build release files for items that live on their own tier and don't have any conflict when installing.

I've got this one application that's become a thorn in my side though... It has about 10 installers that can live on 1 to 10 different machines. Each one of the apps lives in the same directory, and thus, when they go on the same machine, the uninstallers tend to uninstall the other installed files. So I need to figure out 2 things:

1) How do I only uninstall what the previous installer installed?
2) If there are shared files, how do I know that they're potentially shared files, and thus, not uninstall them?

All advise will be much appreciated!

Thanks Once Again,
Eric <><


I can help you on #1
If the old installer is made by you..you can config the old installer to install a setup.cfg or whatever name, but basically an ini file to write the components installed and later you can read it in new installer. You can save installations paths in registry.

If the installer is not made by you, well...you can try deleting the files


Delete $SOMEDIR*.* ; also trt /r for recursive 

>

Similar to what Joel suggested, how about using extended logging with your installer, then employ the Delete Files From Log function from the wiki in your uninstaller? This is something that you can call from another uninstaller as well, keeping track of what each app is installing/uninstalling.

As for shared components, they are always a thorn in one's side. However there are several ways to deal with them, assuming that you are responsible for installing them. What I tend to do, although I am not sure if it is the best strategy, is use the shared DLL key in the registry (HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs) for files that many apps will share. I use this macro to install a shared component and this to remove it. The shared files do not have to be DLL/OCX/TLB nor do they have to reside in $SYSDIR which makes this approach quite generic and useful.

Alternatively you can use the InstallLib macro for shared components.

CF