Com4:ManagedInProcessServer, Class, and ProgId

Paging Fiza_Azmi 

The Com4:ManagedInprocess Server does not support the full range of existing managed Inprocess servers allowed in traditional native COM registrations.

 

For example, here is the registration created by regasm.exe for an existing .Net Framework vendor program.  I am guessing the component isn't even theirs, but from a third party developer that sells components.

 

 

This is an entry that cannot be mapped into the AppXManifest with the current schema restrictions, due to the "+" character in the Class/ProgId string.  There is another unsupported example that uses the underscore character instead of the "+".

 

Here is an example of the mapping of a com registration that complies into the AppXManifest:

<com4:Extension Category="windows.comServer">
<com4:ComServer>
<com4:ManagedInProcessServer Assembly="Geckofx-Core, Version=45.0.32.0, Culture=neutral, PublicKeyToken=3209ac31600d1857" RuntimeVersion="v4.0.30319">
<com4:Class Id="023f6c65-773d-3ca6-a245-031728fc8531" DisplayName="Gecko.nsIFileInputStreamConsts" ThreadingModel="Both" ImplementationClass="Gecko.nsIFileInputStreamConsts">
<com4:ImplementedCategories>
<com4:ImplementedCategory Id="62c8fe65-4ebb-45e7-b440-6e39b2cdbf29" />
</com4:ImplementedCategories>
</com4:Class>
</com4:ManagedInProcessServer>
<com4:ProgId Id="Gecko.nsIFileInputStreamConsts" Clsid="023f6c65-773d-3ca6-a245-031728fc8531" />
<!--AntiDisRegardation fix for Managed ClsId 023f6c65-773d-3ca6-a245-031728fc8531 by TMEditX-->
</com4:ComServer>
</com4:Extension>

 

The ImplementationClass parameter (com4:Class (in com4:ManagedInProcessServer) - Windows UWP applications | Microsoft Learn) is much more limited in the naming conversion traditional supported, as is the ProgId Id parameter (com4:ProgId - Windows UWP applications | Microsoft Learn).

 

Although not explicitly prohibited by the mentioned documentation, the underlying schemas restrict both of these fields to only include alphanumeric characters and the period. 

 

Given that these are commercial components for which we have no access to source code to rename the class implementation, this means that there is no way to support software with these components in them under MSIX.

 

One would guess that this is not an intentional restriction that is required by the underlying systems, and could "easily" be lifted as a restriction.