Jan 14 2022 01:07 PM - edited Jan 14 2022 01:12 PM
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.,
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.
Jan 27 2022 10:14 AM
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).
Jan 27 2022 10:17 AM