Why Should I Care About Application Uninstall?
An application packager’s role is to package content for deployment. Too often the vendor does not consider what happens when their package needs to be uninstalled. Why should I as a packager care about what happens if and when someone decides to remove a package I have built? Windows does not have a good history when it comes to keeping itself clean and tidy, and by ignoring the need to clean up deployments I have authored, I only contribute to that history. It’s time to break the cycle as a packager, uninstall processes needs to have just as much scrutiny as deployment. As the industry moves away from the classic desktop application management model and starts treating enterprise applications like mobile applications, cleaning up a removed package becomes more essential.
Here are some of the areas I check when I build a package to ensure it is fully removed when uninstalling:
1. Program Files Folder – Both x86 and the 64-bit folder
2. Any temporary folder that may be created, check %temp%
3. Any log files that generated as part of the install or uninstall
4. Windows app folders – Don’t forget %appdata% and %localappdata%
5. The Registry – HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE are the primary items, but what about other hives?
6. System files – be careful, because you really can’t be confident that your product is the sole provider/user of a library.
Sure, I can skip this testing and assume that when a new version needs to be applied, everything will go as planned. However, does it every really play out that way? If I don’t know the starting state of my target environment how can I be sure that my deployment will be successful?
By ensuring package removal is complete I am setting up version 2 of my package for success. In the end, I should care about application uninstall because it will help me be successful.