The ComActivator class has no direct dependencies on it anywhere from the managed code. It's also not rooted by anything in the CoreLib's descriptor or otherwise. As such trimming will always remove it.

The class is only used in COM server scenarios. It's referred to from hostpolicy when asked to create COM activation delegate. (also for COM register and unregister delegates).

Note: Currently .NET 5 doesn't support self-contained components and so the most typical COM Server will not actually ever have this problem (since trimming won't make sense for FDD components).

If there is a scenario where a full application also enables COM Server functionality (not sure if this is actually possible currently) then trimming such application would break that functionality.

In theory this might be solvable if we really wanted to:

• There's already an MSBuild property which effectively acts like the COM Server feature switch EnableComHosting - we could turn that into a real feature switch and make the ComActivator rooted conditionally in that case.
• Note that it would not be enough to make COM Servers work, since the classes potentially instantiated by the ComActivator may still be trimmed away. To make this work, we would have tie trimming into the CLSIDMap creation in SDK and make it produce an ILLink descriptor which would root the necessary classes which are registered for COM activation.