ComActivator causes linker to include code which is not needed in most cases

[vitek-karas]

CoreCLR ComClassFactory::CreateInstanceFromClassFactory calls into managed Internal.Runtime.InteropServices.LicenseInteropProxy.Create (and some other methods as well). This dependency is hardcoded in the System.Private.CoreLib descriptor and so linker can't ever remove the LicenseInteropProxy.

This type brings in a lot of dependencies (ultimately even BinaryFormatter) which also have some trim analysis warnings.

This functionality should not be needed when COM support is turned off - see COM Feature switch.

Also - this functionality is probably only needed when managed COM activation is used by the project - that is, it can only ever be called if ComActivator was used.

Vast majority of .NET Core projects don't use ComActivator and thus including this code is unnecessary.

What to do about this:

• Verify that the code in ComClassFactory::CreateInstanceFromClassFactory which calls into LicenseInteropProxy can only be used when ComActivator is also used. If this is not true, then more work is needed to determine what to do.
• Instead of rooting the LicenseInteropProxy always, make it a dynamic dependency (via DynamicDependencyAttribute) of the ComActivator (the right method on it) and remove it from the CoreLib's ILLink descriptor.
• Add a trimming test which validates that the LicenseInteropProxy is not present in a normal console hello world (even without any feature switches)
• Make sure that the code is also hidden behind the COM feature switch (this might be a NOP since ComActivator should be hidden behind the feature switch, but maybe some small pieces will be left-over).

[vitek-karas]

Depending on the outcome of #36659 this might not be needed fully - we may just decide to simply remove the unconditional rooting of LicenseInteropProxy if COM Server scenarios will not be supported with trimming turned on.

[eerhardt]

@LakshanF - is this something you've solved with your trimming work?

[elinor-fung]

@LakshanF - is there still more to do here?

[LakshanF]

I'll double check

[LakshanF]

Closing this now with the following validation,

• With PR Root ComActivator for hosting #54524, BuiltInComInteropSupport is used to control the 3 host APIs. Specifically, when this property is false (default behavior);
  • The helper class, LicenseInteropProxy, is not present
  • The 3 methods in ComActivator as needed by COM Server host is there in a skeleton mode (as in will throw if called from native side to indicate built-in COM support is disabled)
• Ran the COM Server Demo sample under Net6.0 to confirm that it fails when trimmed in the default mode and passes in trimmed mode when BuiltInComInteropSupport is set to true