How does "com4:ManagedInProcessServer" work under a MSIX packaging scenario?

[EZForever]

I'm trying to create a MSIX package for a classic Windows desktop app. The app is written in C# (.NET Framework 4.7.2), and it's running perfectly both before and after packaging.

The problem is that the app exposes a COM class library (also written in C#) for interop with other apps. The original installer of this app registers the COM library with "regasm.exe". Given that MSIX have the ability to expose COM servers, namely with the "windows.comServer" extension, I've tried adding the following extension to package manifest, but it does not work as intended:

<com:Extension Category="windows.comServer">
    <com:ComServer>
        <com:SurrogateServer DisplayName="TheApp Class Library">
            <com:Class Id="8ae249dd-05f8-403e-ac32-00feab49c1f5" Path="TheApp.Library.dll" ThreadingModel="STA" />
        </com:SurrogateServer>
    </com:ComServer>
</com:Extension>

After some research I've found that C# COM libraries registers differently with normal ones; namely it requires a few more entries than DLL path and CLSID written into the registry.

Digging through the documents, I've found that "com4:ManagedInProcessServer" seems to be just what I needed. So I've tried to use the following extension instead:

<com4:Extension Category="windows.comServer">
    <com4:ComServer>
        <com4:ManagedInProcessServer Assembly="TheApp.Library, Version=1.0.0.0, Culture=neutral" RuntimeVersion="v4.0.30319">
            <com4:Class Id="8ae249dd-05f8-403e-ac32-00feab49c1f5" ImplementationClass="TheApp.Library.ExtensionManager" ThreadingModel="STA" Virtualization="disabled" />
        </com4:ManagedInProcessServer>
    </com4:ComServer>
</com4:Extension>

But it still does not work. In fact, this time even the "HKEY_CLASSES_ROOT\CLSID\{...}" registry entries do not get generated. I've checked the AppX deployment logs and no error has ever occurred during package installation. It is as if the extension declaration is not there.

What confuses me more is that "com4:ManagedInProcessServer" does not allow specifying codebase for the assembly. With "regasm.exe" one can specify the full path to COM library with "/codebase", but "com4:ManagedInProcessServer" does not seem to be allowing this.

I've been looking for relevant information for quite some time, but all I could find is the single document page on XML schema (linked above), with no real-world code examples. (And by "no" I mean literally ZERO code example on Internet.) I would like to know if "com4:ManagedInProcessServer" works under the situation described above, and if not so, what should I do to have a C# COM library exposed by a MSIX package?

If it matters, I'm using the latest version of Visual Studio Community 2022 with SDK version 10.0.22621.0. The MSIX package is to be deployed on a Windows 11 23H2 system.

[#2]

@EZForever 

I find the COM documentation difficult to turn into something useful as well.  You first have to know how the COM object is built (meaning old-school terms), and then try to map them into this new registration method using different terms (which I'm sure meant something to someone, but isn't really shared in the documentation).

As a guess, the "Managed" version is related to "managed code" so if you were using regasm to register in the past, you should be in the right ballpark.  When something like the ManagedInProcServer doesn't define the location of the dll, that means you also need another COM extension that maps the dll to something in the ManagedInProcServer element.

It might be you just need to combine both elements in the package (I think surrogate maps to in-process).  But COM4:InProcessServer might be part of the answer as well.

Something that can help would be to download a copy of the Microsoft MSIX Packaging Tool from the Windows Store (free).  Start it up to create a capture and run your regasm against the components.  Stop the capture end go into the editor to look at the AppXManifest it generates.  Then you'll know what you need.

Good luck.  And after you figure it out feel free to feedback button on the bottom of the Documentation page to suggest improvements to the documentation!