[UWP][Desktop Bridge] AppX-Registration of ThumbnailHandler and DesktopPropertyHandler in UWP Desktop Bridge

Question

Hi,

I've created an in-proc Windows Shell-extension, implementing IThumbnailProvider, IPropertyStore (read-only) and IInitializeWithStream. The shell-extension is well-behaved and simply parses the IStream, generates a property-store and provides a thumbnail. It does not change the COM-apartment or call CoInitializeSecurity.

The shell extension is compiled and linked as two DLLs - a x86 DLL and a x64 DLL - to support in-proc loading for both 32- and 64-bit host processes. The COM ClassID for the shell-extension is kept identical in both DLLs.

The 32+64-bit shell extension DLLs will be wrapped into a 32-bit AppX-package, containing the main 32-bit user application.

Questions regarding Desktop Bridge AppX - deployment:
* Is the bitness of desktop2:DesktopPropertyHandler and desktop2:ThumbnailHandler, AppX-package bitness-dependent?
I.e. as the main user application is 32-bit, the shell extension shall also be 32-bit, even though the bitness of the Windows OS is 64-bit?

• What is the proper method to support AppX-deployment of 64-bit shell extensions for 64-bit Windows OS, if the AppX-package is declared as a 32-bit application?

Kind Regards
Andreas Nilsson

Answer 1

Hello,​

Welcome to our Microsoft Q&A platform!

We communicated with the engineer and got a response:

Most extensions in desktop bridge apps, including all of the shell extensions, must be loaded outofproc. This is based on documented Windows 7 and later best practices, but also technically necessary due to details of desktop bridge.

In the documentation of DesktopPropertyHandler see the following in the Remarks section:

Note that the Clsid attribute from PropertyHandler must match the ID attribute under the Class element in the SurrogateServer element from the COM registration in the app manifest.

So there is no need to have both x86 and amd64 version of the extension dll in a package.

Only one of these can be registered in the manifest, and it generally should be the same architecture as declared for the package (an x86 package can be deployed on an x86 or amd64 OS, and if the x86 package registers the amd64 version of its extension dll the extension will be broken on an x86 OS).

Since no version will be loaded inproc by the shell, it doesn’t have to match the architecture of the shell process, it just has to be an architecture supported by the OS.

Thanks

Answer 2

Hi,

Many thanks for the quick and prompt reply.

Regarding the DllSurrogate process:

• Would it be sufficient simply to specify an empty string for DllSurrogate (link:https://learn.microsoft.com/en-us/windows/win32/com/registering-the-dll-server-for-surrogate-activation)

>> .. A DLL server that is designed to always run alone in its own surrogate process is best configured with an AppID equal its CLSID. Under AppID, simply specify a DllSurrogate named-value with an empty string value.. <<

• or, set to "dllhost.exe" (the shell extension is a x86, supporting both x86 and amd64 OS).
  i.e. the os will then execute the 32-bit dllhost-surrogate both in 32-bit OS and 64-bit OS, marshalling the calls between the host and the 64-bit shell?

Many thanks for your help,
Kind Regards
Andreas Nilsson