MultipleDesktopProperty handlers share a single com implementation

[TIMOTHY MANGAN]

This is a reiteration of a previously noted issue that is not resolved.  Some things have changed since I first wrote about it, so it makes sense to clarify here.

Although improvements have been made so that the MSIX Packaging Tool doesn't create invalid manifests for applications structured in the way described below, there remains an underlying issue in the schema restrictions that appears unnecessary, preventing the desired functionality.

This occurs with a package (LibreOffice) that has multiple applications and multiple file types.  The software has a single in-process com object that is a traditional PropertyMetadata Handler. This type of handler maps to the Desktop2:PropertyHandler element which needs a Com Surrogate Server element as well.  Both of these elements must reside within the same application element.  When the application uses this same com dll for file types associated with a different application, it becomes impossible to satisfy the schema restrictions.,

• The desktop2:property handler is tied to the filetypeassociation extension which must be within the application that is used when the fta is involked through things like the shell menu.
• When the desktop2:propertyhandler is added to an application element the surrogate server must reside with that application.
• You cannot add the same Com Surrogate server more than once in the package.

This handler is important functionality to some users, as it allows them to browse through a directory of files in explorer with the preview pane visible and get a peek into what is in the file without having to open each one. For example, the writer program uses it to show properties of text documents, the draw program uses it to show properties of graphic files, and the database program uses it to display properties of the database.

I have previously suggested moving the surrogate server out of the application level to the package level as a possible solution but easing the uniqueness restriction (and making sure appinstaller only does it once) would be possible as well.

[#2]

One possible workaround to this issue would be to use separate CLSIDs under each Application element. Each CLSID would point at the same DLL, and the DLL would funnel all the CLSIDs to the same single implementation object.

This is still ugly in terms of instancing, since there would be a separate exe server created for each application. But it at least lets you share an implementation object across multiple applications with relatively minor code changes (code to associate the multiple CLSIDs with the single implementation during DllGetClassObject).

[#3]

"with relatively minor code changes". Yeah, no source code since we are repackaging a vendor app to deploy in a safe way. These apps will not work in MSIX without changes.