Add the ability to turn off COM support in Windows

[LakshanF]

Applications that do not use COM in windows should have the option to not have any COM related code in their application. We should consider adding a feature switch that will turn off COM for applications in such cases. This feature switch can be ON by default for Windows.

Turning COM support OFF means that the application does not expect any built-in support from .NET to call into COM components (RCW) or allow any other COM Client to call in to the application as a COM Server (CCW).

Setting this feature switch OFF will allow applications to be trimmed in a safe way. Issue #36659 tracks this for trimming.

Given COM support is pervasive in .NET code and also the implicit nature of .NET support for COM, it is challenging to find all the places that will be needed to be touched to turn COM OFF. We can start with the following:

• Add a property to System.Runtime.InteropServices.Marshal to turn off COM. i.e Marshal.IsBuiltInComSupported (internal property) that can be set via a runtime config option, System.Runtime.InteropServices.BuiltInComInterop.IsSupported

• Support for COM Callable Wrapper (CCW)

  • ComActivator.cs
  • The code guarded by the processor directive, FEATURE_COMINTEROP_UNMANAGED_ACTIVATION

• Support for Runtime Callable Wrapper (RCW)

  • The code guarded by the processor directive, FEATURE_COMINTEROP. For example, in Type.InvokeMember

• Type Support

  • Types in System.Runtime.InteropServices including Marshal class, Variant Struct, and some enum values in UnmanagedType
  • Types in System.Runtime.InteropServices.ComTypes

Below are the exceptions:

• ComWrappers is the recommended solution for libraries or apps that use COM and should work even with the built-in COM support disabled

• Keep ApartmentState support

  • The code guarded by the processor directive, FEATURE_COMINTEROP_UNMANAGED_ACTIVATION. For example in Thread class should not be removed
  • ApartmentState is pay-for-play, costs very little and it affects non-COM APIs like WaitHandle

• The first iteration to turn OFF COM support will not focus on removing VM code

[LakshanF]

@AaronRobinsonMSFT, @vitek-karas, @MichalStrehovsky

[AaronRobinsonMSFT]

@LakshanF Does this supersede or contribute to #36659?

[AaronRobinsonMSFT]

/cc @eerhardt

[LakshanF]

@AaronRobinsonMSFT, this is meant to contribute towards #36659. It seems better to have a separate issue to track turning COM off independent of Trimming. Once we have that, #36659 should be the trimmer side work (descriptor file changes, publish related properties etc.) with this switch OFF

[jkotas]

ApartmentState

ApartmentState is pay-for-play, costs very little and it affects non-COM APIs like WaitHandle. I think we should leave it as is, independent on this switch.

[AaronRobinsonMSFT]

Support for COM Callable Wrapper (CCW)

Is independent of the COM Activation scenario. CCWs are created whenever a managed object is marshalled as an "interface" across the managed/native boundary - which means one can pass a managed object through a P/Invoke.

Support for Runtime Callable Wrapper (RCW)

Appreciate the callout of the two wrapper concepts and we can think about them distinctly here. From a technical standpoint however, they are so intertwined that there is no way to address them independently - even at the scenario level. For example, COM Aggregation which merges a wrapper of each type.

[jkotas]

Note that majority of the COM support is in the unmanaged VM code today. This will need to disable the COM support on number of places in the VM too to be consistent and complete.

Also, this should not affect ComWrappers. Pay-for-play interop implemented via ComWrappers should continue to work even when the built-in COM support is disabled. ComWrappers should be our recomended solution for libraries or apps that use COM and would like to work even with the built-in COM support disabled.

the application does not expect any explicit support

Nit: "explict" does not sound right to me in this context. It may be better to describe it as "built-in support".

[elinor-fung]

Should turning off dynamic keyword support for COM objects also be included here (it only works for the built-in __ComObject type)? That would all be under ENABLECOMBINDER in Microsoft.CSharp.

[kant2002]

I take a look at runtime repository and usage of ComImport attribute,
so far only following assemblies

• System.DirectoryServices
• System.DirectoryServices.AccountManagement
• System.Management
• System.Speech

Each of this assemblies has about 6-10 classes decorated.
Is there plans how to make functionality which depends on these classes work in disabled-COM world?

[AaronRobinsonMSFT]

Is there plans how to make functionality which depends on these classes work in disabled-COM world?

I don't think there is a present plan for that. It is going to require some auditing of the systems to ensure they don't depend on features of COM that would be difficult in a ComWrappers environment (for example, IDispatch). The WMI system (System.Management) is very dynamic and I am not sure it is worth investing in, similar for System.DirectoryServices*. In practice I think we will let the community drive these decisions unless we hear there is a pressing need.

[LakshanF]

Closing this given the planned work was completed