Repository navigation
[Feature] Toast Notification Uninstaller improvements #4056
Description
Describe the problem this feature would solve
According to the documentation the uninstaller of an unpackaged Desktop app should call ToastNotificationManagerCompat.Uninstall(); to "clean up any scheduled and current notifications, remove any associated registry values, and remove any associated temporary files that were created by the library".
I had a look in the code and it looks like this method only cleans up data of the current user and some global if the current running application has elevated permissions. Therefore, for example notifications of other users are not removed.
Also, an installer may not have the same app id because it may be a totally different program (uninstall.exe or msi). Because this method does not have an app id parameter it cannot be used to uninstall other programs.
Describe the solution
If the uninstaller has elevated permissions, the uninstall method should also clean up notifications and data of other users.
Also, a new optional parameter app id should be added.
Until this is implemented, this missing clean up should be mentioned in the documentation.
Describe alternatives you've considered
According to the documentation it is ok not to call the uninstall method on closing of a portable app if notifications should still be shown after the app was closed. If the impact of not calling this method is minimal, maybe it can be completely omitted?
An uninstaller usually does not need Toast Notifications, so the Notification library usually is not linked. As an alternative, the uninstaller may delete registry keys or folders directly without calling the uninstall method. But I do not think this is a good approach because of the manual labor.
Another option would be to let the uninstaller call the normal application using some command line parameter to only call the uninstall method.
Activity
michael-hawker commentedon Jun 1, 2021
FYI @andrewleader thoughts on this?
Kyaa-dost commentedon Jun 1, 2021
@ChristianGalla Thanks for providing detailed information and showcasing multiple options. Going to open this up for the rest of the community and see what they think 🤔
CC: @andrewleader
andrewleader commentedon Jun 1, 2021
Excellent feedback :) I'm definitely looking forward to seeing if others have feedback or thoughts on this, but I'll add some info/clarifications...
You asked "If the impact of not calling this method is minimal, maybe it can be completely omitted?"
Uninstall()isn't called.Uninstall()properly gets called is if the app uses scheduled toast notifications (otherwise the user would receive a notification after they uninstalled the app). Aside from that, the only other primary concern is that previous notifications might still be in Action Center, however that's a pretty small concern. Additionally, registry keys would still be left if Uninstall isn't called, but it really isn't a sizeable amount so I'm not too concerned about that personally. There are also ways we could improve cleanup of stale keys (we could possibly have the library check through all keys every 15 days and remove ones that haven't been used if this does become a concern, that'd be the fool-proof way of addressing that concern).You certainly raise a really great point about the uninstaller having a different app ID and therefore not being able to correctly uninstall for the app... there is potential for improving this, by adding an AppId or some other overload.
In the future, we're bringing these APIs to Project Reunion, where there might be more of an organized uninstall system. Any customer feedback here will certainly influence how the Project Reunion notification APIs will be built and function, so it's very valuable learning what's important to users!
Looking forward on other people's thoughts on Uninstall and what their requirements are!
ChristianGalla commentedon Jun 2, 2021
I think the footprint of some registry keys is minimal and can be ignored. I do not think there is any uninstaller that removes old registry keys and cleans up data from the profile folder of other users. I think this would be hard to implement for example for roaming user profiles.
Is there any use case to show (timed) notifications for programs that are not available anymore? I do not think there is any useful interaction possible. I suggest Windows should check if the program that scheduled the notification is available before showing the notification.
Regarding old notifications: Maybe on login Windows should remove all old notifications of programs that are not available anymore. Regarding this idea, I am not certain, because for example a program may be deployed on a network share that is temporary not available because the computer is not connected to the company network.
Daniellled commentedon Apr 6, 2022
It also appears if you run the Uninstall() method as a different user, run your application using the "Run As" command. It will uninstall the notifications for the current session. Not the user the application is running as.
In general I was wondering if any progress has been made on this issue?
andrewleader commentedon Apr 6, 2022
Hey @Daniellled, the Windows App SDK team is working on adding the notification features seen here to the Windows App SDK, so all work within the WCT has been effectively paused.
Version 1.1 of the Windows App SDK has an initial version of the notification API, supporting registering and sending notifications (but is missing the XML builder APIs so you still have to either use raw XML, or can use the WCT to build the XML).
Supporting clean uninstall is definitely something that will be more achievable from within the Windows App SDK. I'm not sure whether 1.1 supports that, you could ask a question on the Windows App SDK repo :) https://github.com/microsoft/WindowsAppSDK/discussions