Discrepancy in Windows built-in COM support between native and managed sides

[LakshanF]

.NET has the ability to disable interop support in Windows for built-in COM via a feature switch in .NET6. However, there is an observable behavioral difference mismatch in native and managed side when built-in COM is disabled. This is primarily due to the native side lacking dynamic checks in Windows native code. There is a static configuration flag, FEATURE_COMINTEROP, that is used in non-Windows platforms that is effective in those platforms (since the code is removed in those builds) but can cause problems in Windows when built-in COM is disabled. Issue #55600 highlights a way this can be bubbled up.

Although this feature switch originated from Trimming requirements and the behavioral differences can be flushed out currently via trimmed applications (trimmer removes types and members from managed side that native side depend on), this discrepancy exist independent of trimming. It will be good to treat it as such and ensure that the differences are addressed. Native side has a flag, IsBuiltInCOMSupported(), that can be leveraged for dynamic checking.

Some options that could be leveraged (from a discussion with @vitek-karas) for this;

1. CR of the native side where built-in COM is used (The configuration flag, FEATURE_COMINTEROP, guards these places statically currently). The downsides are that this code is spread in many locations and risks with future changes
2. Add a testing mode to leverage existing test bed (add an assert for code guarded by FEATURE_COMINTEROP)