Uninstalling a problem package
Hi,
I'm just looking for some best practice advice on uninstalling a package which utilises the selfreg table. I have a package allocated across the site, which registers some VB runtime and cyrstal report DLLs via selfreg. I suspect that if I simply deallocate the package from the clients, these shared DLLs will become unregistered.
Therefore, would you suggest I
1) Leave the package allocated. Obviously this will mean that it gets installed whenever a client is rebuilt. Not a major problem, just untidy really.
2) Zap Windows Installer's reference to the MSI with Windows Installer CleanUp and leave the files and registry alone.
3) As above, but script the deletion of files and reg values.
4) Script the re-registration of the DLLs once the package has been uninstalled.
If there's another way of doing it, I'd obviously like to hear about it.
This was a vendor-supplied repackaged MSI (using Wininstall LE 2k), which I deployed before being aware of the problems associated with selfreg.
I'm just looking for some best practice advice on uninstalling a package which utilises the selfreg table. I have a package allocated across the site, which registers some VB runtime and cyrstal report DLLs via selfreg. I suspect that if I simply deallocate the package from the clients, these shared DLLs will become unregistered.
Therefore, would you suggest I
1) Leave the package allocated. Obviously this will mean that it gets installed whenever a client is rebuilt. Not a major problem, just untidy really.
2) Zap Windows Installer's reference to the MSI with Windows Installer CleanUp and leave the files and registry alone.
3) As above, but script the deletion of files and reg values.
4) Script the re-registration of the DLLs once the package has been uninstalled.
If there's another way of doing it, I'd obviously like to hear about it.
This was a vendor-supplied repackaged MSI (using Wininstall LE 2k), which I deployed before being aware of the problems associated with selfreg.
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
brenthunter2005
18 years ago
Check the original MSI. Those files may have the component bit set to be permanent, and therefore may not need to be unregistered etc.
Posted by:
kkaminsk
18 years ago
I really don't like touching shared dlls in this case because of the potential to break something else. If the shared dlls are registered from common file folders I would definately leave them alone. If the are with the app I would try to go on a fact finding mission to see if other apps are using those COM registrations as a matter of due diligence. Or you could just skip that and test different portions of the client population to see if anything breaks and get more agressive with the deployment if nothing breaks.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.