A: There are a dozen ways to do this correctly. Which right way should we pick?
B: I don’t know, I found this code on the internet. Should I just use it?
A: Sure, if it’s on the internet it must be the right way.
I... don't think so? The particular problem here, is that an uninstaller executable needs to delete itself from disk after doing its main job.
Other than using MoveFileEx with a NULL destination file and the MOVEFILE_DELAY_UNTIL_REBOOT flag, then suggesting/forcing a reboot, I can't think of a straightforward solution.
And that solution instantly lights up your JIRA with 2 tickets:
#1: We MUST not suggest/force a reboot! Users hate it!
#2: CRITICAL BUG: uninstaller.exe still present after uninstalling product
So, then you try things like 'create a Task Scheduler job to delete the file', which then adds:
#3: PRIO 1: uninstaller.exe crashes if Windows Task Scheduler disabled
#4: SHOWSTOPPER: uninstaller.exe still not always deleted after uninstall. Why is this so hard?
Et cetera, ad absurdum. This then escalates to code injection (as described in the linked article), and (you heard it here first) kernel-mode drivers. So, if you're aware of a reliable solution, feel free to share in a comment here, for the betterment of the world!
And what's the problem with this?
> When our product’s uninstaller sees an undeletable file (possibly a DLL loaded in another process), it uses the MOVEFILE_DELAY_UNTIL_REBOOT flag to mark it for deletion, and warns the user “Please reboot as soon as possible to remove the remaining files.”
> However, some user uninstall our product, just to be able to reinstall it later, to the same location. And of course they ignored the warning. Once they reinstalled it, everything works, until a reboot.
That solution instantly lights up your JIRA with 2 tickets: #1: We MUST not suggest/force a reboot! Users hate it! #2: CRITICAL BUG: uninstaller.exe still present after uninstalling product