Add the ability to remove COM support using ILLinker

[eerhardt]

As discussed in:

• Remove remaining ILLinkTrim.xml from libraries #35199 (comment)
• Run illink task with at the end of build #31712 (comment)

We are currently "rooting" types in the libraries specifically for COM:

runtime/src/libraries/Microsoft.CSharp/src/ILLinkTrim.xml

Lines 7 to 8 in 0955d7f

	<!-- Required for COM event dispatch -->
	<type fullname="System.Runtime.InteropServices.ComEventsSink"/>

runtime/src/libraries/System.Runtime.InteropServices/src/ILLinkTrim.xml

Lines 3 to 4 in 0955d7f

	<!-- IMarshal is internal and never directly called, but needed by COM -->
	<type fullname="System.Runtime.InteropServices.IMarshal" />

A lot of scenarios in .NET don't have COM support, as such we should be able to trim out any COM specific code when we are linking for a scenario that won't ever need COM (Blazor, Xamarin, Linux, etc).

One way of doing this would be to add a new feature switch to the product that would enable/disable COM. We can then add the switch in code to remove any COM specific code. In order to remove the COM types from being rooted by the ILLinkTrim.xml "descriptor XML files" above, we would need the ILLinker to allow "feature switches" to be present in the descriptor XML files, and to include/exclude that root based on the feature switch.

Note that Blazor today is already using something similar when it uses monolinker.exe - --exclude-feature com. See the Blazor build code. However, --exclude-feature is not supported by the ILLinker, only by monolinker.exe.

cc @vitek-karas @MichalStrehovsky @sbomer @marek-safar

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[marek-safar]

In this case, I'd prefer to see a new public property for COM. Something like RuntimeFeatures.IsCOMSupported and use that for all COM related code inside libraries including ComEventsSink or IMarshal dependencies.

[AaronRobinsonMSFT]

@vitek-karas and @MichalStrehovsky I would be grateful if one of you could provide some suggestions on the best way to solve this issue.

[jkotas]

Both IMarshal and ComEventsSink roots above are instances of dotnet/linker#936 . What are the plans for ComImport support in the linker?

[marek-safar]

Linker has all the required features needed to make COM support feature-based. The ball is on the libraries side to decide what level of granularity is needed and add the API (static bool property/properties).

[jkotas]

Ok, my proposal would be bool Marshal.IsComSupported, returns true by default on Windows and false by default on Unix. Does it need to be public API, or can it just be internal (for now at least)?