-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
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.Marshalto turn off COM. i.eMarshal.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
- The code guarded by the processor directive,
-
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 code guarded by the processor directive,
-
The first iteration to turn OFF COM support will not focus on removing VM code