4

My Win32 application needs to install a Windows Explorer Shell extension.

I've used Desktop App Converter to generate AppX for my application. But the converter ignored the shell extension installed by a legacy installer of the application.

While it captured the Classes\Directory\shellex key to Registry.dat, the key entries point to CLSID that was not captured. And even if it did capture the referenced CLSID, it points to a path, where legacy installer installs the application, not to a real location where AppX will be installed.


I was thinking about registering the extension by the application itself on the first run. But the installation location in C:\Program Files\WindowsApps has restricted permissions, so regsvr32 fails.

The module "C:\Program Files\WindowsApps\WinSCP_5.14.0.0_x86__2dz6xbp7ps3z2\DragExt64.dll" failed to load.

Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.

Access is denied.


The permissions do allow the file to be copied elsewhere though. So I could copy the .dll to for example user profile (C:\Users\...) and register it from there. But that would leave the .dll behind, when the AppX is uninstalled.

Is there any better solution?

Community
  • 1
  • 1
Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
  • AFAIK Registring shell extensions requires modifying system registry which is not possible in a Desktop Bridge app, no matter which path you go through. Desktop Bridge apps are isolated when it comes to editing system registry. – Mehrzad Chehraz Apr 18 '18 at 12:23
  • @MehrzadChehraz Yes, it's possible. But maybe there's an alternative way, like there's for registering file extensions. – Martin Prikryl Apr 18 '18 at 12:27
  • [Here](https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-behind-the-scenes) you can find that when you write to registry, you write to a local .dat file not the actual system registry. Also, regsvr32 needs administrator permission while Desktop Bridge apps run on the user context not as administrator. – Mehrzad Chehraz Apr 18 '18 at 12:29

1 Answers1

8

The design principle for packaged Win32 apps on Windows 10 (Desktop Bridge apps) is that they integrate with the Shell in a declarative way via the appxmanifest (not via registry). To facilitate this we have added Shell extensions to the manifest scheme. The system will run those extensions out-of-proc with the Shell (unlike classic in-proc extensions), to allow seamless app updates and to prevent apps from the crashing the Windows Shell/Explorer.

See here for documentation: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-extensions

EDIT Note that not all existing Shell extensions are supported today. To help us prioritize any that are still missing, please log them on UserVoice: https://wpdev.uservoice.com/forums/110705-universal-windows-platform

Stefan Wick MSFT
  • 13,600
  • 1
  • 32
  • 51
  • Thanks for your response. My shell extension implements `ICopyHook`. It does not look like that this is supported in Desktop Bridge extensions. – Martin Prikryl Apr 19 '18 at 09:29
  • 1
    Yes, this one is still on the backlog for Desktop Bridge applications. I have updated my answer with info on how you can help us prioritize the Shell extensions that are not yet supported in Desktop Bridge apps. – Stefan Wick MSFT Apr 19 '18 at 15:09
  • To help with the tendency of the right click menu to become bloated, I would like to be able to toggle an extension. (with a checkbox in the app's options menu) Is there a way to do this that isn't restricted for converted apps? – jbcarpen Apr 25 '18 at 19:12
  • The link to uservoice is broken. Are there any plans to add Shell Namespace Extension in Windows 11? Or are there any replacement for them on Windows 11? – user16668952 Sep 29 '21 at 10:20