MSIX: ability to offer and uninstall previous desktop installation if it exists

[yuyoyuppe]

Summary of the new feature/enhancement

This article provides some insights into how to smooth out MSI to MSIX transition.

It would be nice to be able to detect previous PowerToys MSI installation and offer a user automatic uninstall of it like the article shows.

Proposed technical implementation details (optional)

• detect if we're in UWP context on runner startup
• if so, run a background thread which searches for an existing MSI installation
• if it's present, show a confirmation dialog and uninstall it
• report the uninstallation result as a tray notification (low priority info for the user, so using the least intrusive way)

[crutkas]

@GrantMeStrength Is there a page on docs.microsoft.com? If not i feel like we should migrate this over there for newer patterns. I don't see it under the root https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-root

@qmatteoq Any other updated bits from that blog post? It is 2yrs.

[yuyoyuppe]

@crutkas Btw, while implementing a first draft of this feature, I've encountered a funny issue. I was able to detect a previous installation from MSIX using MSI API from the runner. Subsequently, I've tried to uninstall it from the MSIX runner process, however, the first thing the uninstaller does is terminates all PT process, which means terminating us and the uninstallation proccess with it.

We could prevent this self-terminating loop by uninstalling in a separate process by just invoking the msiexec.exe, but that won't resolve the fact that we need to restart PT after it's been terminated.

I think it's high time to implement #1020, since it'll allow us to terminate two birds with one stone:

1. allow a user to confirm the uninstallation at any time, even when PT isn't running
2. allow for the uninstallation process to proceed w/o terminating itself

The second point stands, because toast notifications could be activated using a cross-process COM call to a separate executable serving as an activation handler.

How do you think we should proceed?

[qmatteoq]

Hey @crutkas, no changes have happened in the migrate area. That blog post is still relevant, even if it's 2 years old.

[crutkas]

I think it's high time to implement #1020, since it'll allow us to terminate two birds with one stone:

1. allow a user to confirm the uninstallation at any time, even when PT isn't running
2. allow for the uninstallation process to proceed w/o terminating itself

The second point stands, because toast notifications could be activated using a cross-process COM call to a separate executable serving as an activation handler.

How do you think we should proceed?

@yuyoyuppe, i worry about notifications honestly. I get fatigue with them and we'd need to verify people actually would take action / the app itself shows the user that notification as well since they may miss it.

[yuyoyuppe]

@crutkas what if we just show the notification each time the app starts, but offer a "don't show this again" tick?

[crutkas]

1. This is a limited time issue due to us shipping a few versions early with MSI.
2. yes it is a scenario we should deal with
3. why are we 'offering' versus just doing? We wouldn't want two versions of PT installed on the same machine.

[enricogior]

why are we 'offering' versus just doing? We wouldn't want two versions of PT installed on the same machine.

Because we can't do this while installing MSIX and because we don't have admin privileges to do it anyway.

[crutkas]

can we do it at runtime like the blog is stating in User Transition: Uninstall previous desktop app section?

[enricogior]

@crutkas
without asking the user first? Since the UAC will appear, shouldn't PT first alert the users that an uninstall will be started?

[crutkas]

Doesn’t the sample code do just that? It prompts and directly asks if they want to uninstall the old version. Am I misreading the blog post?