Using IApplicationActivationManager::ActivateForFile does not work for packaged apps

[lhak]

Describe the bug

Trying to activate a packaged windows app sdk application using the IApplicationActivationManager::ActivateForFile method (e.g. from a Windows 11 explorer context menu entry component) fails with the following error message:

0x80270254: This app does not support the contract specified or is not installed.

The FileTypeAssociation extension is defined in the manifest and the app can be successfully activated from the corresponding explorer legacy context menu entry. The same manifest entry also works fine for a UWP application.

Interestingly, using the ActivateApplication method works correctly.

Steps to reproduce the bug

1. Try to start a packaged appsdk application with the ActivateApplication method -> works
2. Try to start the same app with the ActivateForFile method -> does not work
3. Try to start a UWP application with the ActivateForFile method -> works

Expected behavior

The ActivateForFile method should work in the same way as for UWP apps.

Screenshots

No response

NuGet package version

1.1.4

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 21H2 (22000)

IDE

Visual Studio 2022

Additional context

No response

[DrusTheAxe]

Activation is more @kanismohammed's area of expertise

[kanismohammed]

@lhak - IApplicationActivationManager APIs are predominantly used for launching UWP applications (Core Application bases apps). They should not be used for launching Windows app sdk apps. Please use ShellExecute to launch the application.

[lhak]

@kanismohammed So how can launch the application so that I receive a list of files in the activation parameter (FileActivatedEventArgs) as it happens when using the legacy Windows 10 context menu entry? ShellExecute seems to only allow for a single file to be passed.

[DrusTheAxe]

@lhak - IApplicationActivationManager APIs are predominantly used for launching UWP applications

That's inaccurate. AAM is the API to launch a packaged app by its AUMID (regardless of the type of packaged app - Universal or not).

IF the package declares an AppExecutionAlias for a packaged app then CreateProcess|ShellExecute can be used to launch the AppExecutionAlias and thus the app (an indirect way to "run the app's exe").

IF the package declares an <Extension Category="windows.shortcut"> for a packaged app then CreateProcess|ShellExecute can be used to launch the shortcut (.lnk file) and thus the app (another indirect way to "run the app's exe").

IF the app's executable has an embedded Fusion manifest with an <msix> element then CreateProcess|ShellExecute can be used to launch the executable (on 20H1+).

IF the app's executable is unambiguous across apps in the package (i.e. the exe is only specified for 1 <Application> in the package) then CreateProcess|ShellExecute can be used to launch the executable (on >=Win11).

Manifested AppExecutionAlias and Shortcuts require the developer declared them in their package i.e. not viable for all packaged apps. The Fusion <msix> and directly executing the exe on Win11+ require an absolute path that's not stable (packages are in ProgramFiles\WindowsApps\pkgfullname directories so that pkgfullname element changes every time a package is updated). These are all useful tech, but not complete replacements for IApplicationActivationManager.

[kanismohammed]

@lhak - this stackoverflow discussion (https://stackoverflow.com/questions/22181788/shellexecute-multiple-files) has the answer to your question.

[mcooley]

It would be very helpful to me if IApplicationActivationManager::ActivateForFile wasn't limited to UWP apps.

I have some integration tests which verify that my full-trust app works when launched with a file (even if my app is not the default handler for that file). Without ActivateForFile, I have to enumerate all handlers, find the one that belongs to my app, and invoke it. None of the APIs which enumerate file associations work well for this purpose: with IContextMenu or IAssocHandler I can't reliably determine which handler matches my package; with Windows.System.Launcher I can't reliably get the ID of the process which was launched. ActivateForFile would fill this gap if it worked.