I am grateful to see the response to the previous query looking for guidance on implementing Extensions in the AppXManifest, namely Extensions in the package manifest schema - Windows UWP applications | Microsoft Docs.
The concept of separation of app specific extensions versus package-level (applying to all apps in the package) might need a bit of tweaking, and thus tweaking of the supported element lists in that documentation.
While multi-application packages are one reason for package level extensions, another is package extensions that are (or could be) unrelated to a specific application. A key example would be in-process com extensions that are intended for applications outside of the package. Currently all com extensions must be placed under an Applications/Extension, and there is support for in-process COM dlls to be added as a Surrogate in the manifest, at least from a validation standpoint but they don't work. Shell Extensions are an example of this, where the explorer.exe process should integrate them
into the explorer process, but publishing in-process shell extensions for consumption by other application level processes not in the package has been traditionally supported.
So I believe the list of package level extensions should be extended, starting with the shell extensions. However, it is possible that Microsoft wants to support the concept of shell extensions without adding them directly into the explorer.exe process (for security issues). Which is OK, as long as we can get support for traditional shell extensions. In computing, it is really all about the data and end-users don't always start with the app, but the data file. Integrated shell commands are not enough, and shell extensions have been a long-standing solution. While some shell extensions have been migrated to independent Manifest elements for support, most have not. I believe Microsoft has some work to do here, and a roadmap (even without dates and just saying this is in or out of scope) will be helpful to developers WANTING to move their existing applications to MSIX.
... View more
Shell Extensions, such as Context Menu Handlers have been sought after in MSIX for quite a while. While the Microsoft MSIX Packaging Tool does not support them (today), there is plenty of evidence from Microsoft that they should be possible.
In particular, I point to the following article:
Modernize existing desktop apps using Desktop Bridge - Windows applications | Microsoft Docs
which shows an example. (The example is clearly incorrect, as the Application element required an Id attribute and VisualElements subnode. While an older example, it is not deprecated and it is not uncommon for desktop bridge documentation to be referenced for MSIX, even if not perfect. Even through shell extensions don't necessarily tie to an exe inside the package when implemented as an in-process com object in the file explorer, we can usually find an application in the package to leverage to overcome this).
It does not seem possible to get this example (nor any other) to work. Can we get some feedback on the status of shell extensions? Is it that:
There are gaps in the documentation that need addressing but they work if specified correctly.
It is supposed to be working, but there are bugs in the implementation (AppInstaller and or runtime) that need fixing.
Microsoft is still working on a complete implementation and customers should be patient.
Microsoft has decided not to support the functionality going forward.
... View more
Bumping this thread to ideas section for @John Vintzel
... View more
Welcome to the MSIX Tech Community. Connect, learn, and discuss topics on various aspects of MSIX. We will keep you posted with events involving MSIX and stay tuned for links to sessions, announcements, and availability of new features of MSIX.