Status of Shell Extensions like Context Menus

Status of Shell Extensions like Context Menus
0

Upvotes

Upvote

 Jan 04 2021
5 Comments (5 New)
Completed

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.
Comments

Bumping this unaddressed question on Shell Extension Context Menus.

 

Are they supposed to work or not?  If so, an example manifest would be quite helpful.

Brass Contributor

It is interesting to see that apps, such as Skype have implemented this successfully.

See the manifest below of the Skype app.

 

<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="Skype Share">
<com:Class Id="776dbc8d-7347-478c-8d71-791e12ef49d8" Path="Skype\SkypeContext.dll" ThreadingModel="STA" />
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop4:ItemType Type="*">
<desktop4:Verb Id="ContextMenu" Clsid="776dbc8d-7347-478c-8d71-791e12ef49d8" />
</desktop4:ItemType>
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>

 

When looking at the Microsoft example;  ExplorerCommandVerb.

It does work, but only for registered extensions and only when it is the default app.

It however uses different parts in the app manifest.

        <uap3:Extension Category="windows.fileTypeAssociation">
          <uap3:FileTypeAssociation Name="test" Parameters="&quot;%1&quot;">
            <uap:SupportedFileTypes>
              <uap:FileType>.test</uap:FileType>
            </uap:SupportedFileTypes>
            <uap2:SupportedVerbs>
              <uap3:Verb Id="Edit" Parameters="&quot;%1&quot;">Edit in testapp</uap3:Verb>
            </uap2:SupportedVerbs>
          </uap3:FileTypeAssociation>
        </uap3:Extension>
        <com:Extension Category="windows.comServer">
          <com:ComServer>
            <com:SurrogateServer DisplayName="ContextMenuSample">
              <com:Class Id="CC19E147-7757-483C-B27F-3D81BCEB38FE" Path="ExplorerCommandVerb.dll" ThreadingModel="STA"/>
            </com:SurrogateServer>
          </com:ComServer>
        </com:Extension>

Trying and adding the * for file extensions doesn't work.

Also adding the fileExplroerContextMenus option with a wildcard, fails to deliver succes.

        <desktop4:Extension Category="windows.fileExplorerContextMenus">
          <desktop4:FileExplorerContextMenus>
            <desktop4:ItemType Type="*">
              <desktop4:Verb Id="Command1" Clsid="CC19E147-7757-483C-B27F-3D81BCEB38FE" />
            </desktop4:ItemType>
          </desktop4:FileExplorerContextMenus>
        </desktop4:Extension>

 

Looking at the Skype app and other apps, it should be possible to have a generic context menu handler. However it seems very difficult to find an example/source of working code. It would help greatly if Microsoft could share the source of SkypeContext.dll

 

@Sander de Wit One thing I have seen that you must consider is dependencies.  Often, shell extensions require a VC Runtime present, and while it might be in your package, it is the explorer process running outside of the container that needs this present. 

 

I have applied the VCRuntimes to the base OS to solve other types of Shell Extensions, but it hasn't helped with the Context Menu shell extensions I have been working with.  Perhaps there are other dependencies on those that I haven't figured out yet...

Microsoft

Marking completed with the work in Windows 11.

 

Support legacy context menus - MSIX | Microsoft Docs

Microsoft
Status changed to: Completed