Uninstallation Approach for COM
Hello,
How should I take care of a COM component (In my case it is a Browser Helper Object and at least a single instance of IE is running) that is currently being loaded/used by IE.
Another question: I can have a Custom Action that will delete all files that were created at run time and NOT by the installer. But there could be a file(s) that was copied to my application folder by mistake. I don't want my custom action to touch any such file. I know it sounds weird but that is what the requirement is.
Cheers,
How should I take care of a COM component (In my case it is a Browser Helper Object and at least a single instance of IE is running) that is currently being loaded/used by IE.
Another question: I can have a Custom Action that will delete all files that were created at run time and NOT by the installer. But there could be a file(s) that was copied to my application folder by mistake. I don't want my custom action to touch any such file. I know it sounds weird but that is what the requirement is.
Cheers,
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
Reading between the lines, your first question is really 2 questions:
- how do I uninstall a COM object?
- how do I handle the fact that IE might be running and will interfere with the uninstall?
So,
- your MSI ought to have incremented the shared DLL count so that, if other apps are using the DLL/OCX, your uninstall won't remove it or its COM registration details. If there's only usage, the WI engine will take care of its removal, again assuming that your MSI was properly authored. If it didn't increment the count, I think the safest thing to do is leave it alone.
- handling IE is a tricky one. The ploite thing to do would be check if IE is running and, if it is, prompt the user to close it. Some clients, however, dictate that running apps be simply killed. My view is that users don't much like being kicked out of their apps but if that's what the client wants and the Packager's Baseball Bat method fails, then that's what they get.
As to your rogue file dilemma, you will need to use the relatively little-known and poorly documented object ReleasePackagers.PsychicPowers. Use your crystal ball to check syntax and so on.
- how do I uninstall a COM object?
- how do I handle the fact that IE might be running and will interfere with the uninstall?
So,
- your MSI ought to have incremented the shared DLL count so that, if other apps are using the DLL/OCX, your uninstall won't remove it or its COM registration details. If there's only usage, the WI engine will take care of its removal, again assuming that your MSI was properly authored. If it didn't increment the count, I think the safest thing to do is leave it alone.
- handling IE is a tricky one. The ploite thing to do would be check if IE is running and, if it is, prompt the user to close it. Some clients, however, dictate that running apps be simply killed. My view is that users don't much like being kicked out of their apps but if that's what the client wants and the Packager's Baseball Bat method fails, then that's what they get.
As to your rogue file dilemma, you will need to use the relatively little-known and poorly documented object ReleasePackagers.PsychicPowers. Use your crystal ball to check syntax and so on.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
