com4:ManagedInProcessServer equivalent for out-of-proc servers

[reflectronic]

In Windows 11, support for registering in-proc servers implemented with .NET Framework was added through com4:ManagedInProcessServer:

<com4:ManagedInProcessServer Assembly="Fabrikam.Widgets, Version=10.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxxx" RuntimeVersion="v4.0.30319"> 
  <com4:Class Id="99b9b8fa-2c14-42f7-xxxx-xxxxxxxxxxxx" DisplayName="SimpleWidget" ImplementationClass="Fabrikam.Widgets.SimpleWidget"/> 
  <com4:Class Id="0057c8be-3c95-4242-xxxx-xxxxxxxxxxxx" DisplayName="SingleThreadedWidget" ImplementationClass="Fabrikam.Widgets.SingleThreadedWidget" ThreadingModel="Apartment"/> 
</com4:ManagedInProcessServer> 

Is it currently possible to create an equivalent that registers an out-of-proc server instead (e.g. through a DLL surrogate)? It does not appear to be possible with com:SurrogateServer as it exists currently, since .NET Framework servers are expected to be launched through mscoree.dll; the actual path to the implementing assembly and type is written through extra values (InprocServer32\Class, InprocServer32\Assembly, InprocServer32\RuntimeVersion).

One could imagine that this would be useful for e.g. writing a simple implementation of IExplorerCommand without dropping into C++.

@DrusTheAxe

[DrusTheAxe]

<com4:ManagedInProcessServer> = https://docs.microsoft.comuwp/schemas/appxpackage/uapmanifestschema/element-com4-managedinprocessserver-class

Is it currently possible to create an equivalent that registers an out-of-proc server instead (e.g. through a DLL surrogate)?

That's a great question. +@brialmsft as more familiar with MSIX's Packaged COM support

[reflectronic]

Is there an update on this? Obviously, it's not strictly necessary, since I can just implement the server as an EXE and register the class objects as usual. It's just that .NET doesn't have any primitives that handle the server lifetime, and implementing it complicates the implementation a lot (especially because the objects will hang around, even if there are no outstanding references, until a GC is triggered).

If there's a simple way to use the default DLL surrogate for this, it'll reduce the complexity/scariness of the code by a lot. Of course, if this requires a new Windows feature, the appeal decreases a bit since it will be a while before it's broadly available in-market (unless WASDK can somehow polyfill this activation).

[brialmsft]

@reflectronic Unfortunately, this isn't currently possible, and would require OS changes to support properly. We don't have a timeline for prioritizing this work.

An alternative to completely switching to an exe would be to have a native surrogate DLL which acts as a shim and activates the real class from the managed DLL (which would be configured in the package's private registry.dat rather than the manifest). Certainly still carries some complexity for the native shim, but avoids having to deal with lifetime management.

For reference, the work item number tracking this gap on our end is 24929515 (mostly for the benefit of any MSFT folks looking at this thread).

[DrusTheAxe]

For reference, the work item number tracking this gap on our end is 24929515 (mostly for the benefit of any MSFT folks looking at this thread).

https://task.ms/24929515 for linky convenience :-)