API suggestion: RuntimeFeature.IsComActivationSupported

[GrabYourPitchforks]

Related: #34328

namespace System.Runtime.CompilerServices
{
    public static partial class RuntimeFeature
    {
        public static bool IsComActivationSupported { get; }
    }
}

This API answers the question "Does the current environment support Type.GetTypeFromCLSID (or CoCreateInstance in general)?" This API returning true doesn't guarantee that a particular COM instantiation will succeed. The API returning false means that COM activation APIs will throw PNSE so the caller shouldn't bother.

[jkotas]

Note that there many other parts of COM not implemented by Mono. COM activation is just a small part of it.

#35079 is about adding test project property (e.g. PlatformDetection.IsComSupported) to disable tests that use COM against.

I do not see the value of public API(s) for this. Catching the PlatformNotSupported exception should be sufficient for the few situations that need it.

[GrabYourPitchforks]

I have in mind applications that might attempt to instantiate plugins via registered COM interfaces. The idea is that they could perform feature detection to avoid using a COM based plugin model at all if they know all the calls will fail.

Your suggestion instead is that these apps should attempt COM instantiation anyway, treating the exception as "feature unavailable" rather than as a configuration error that requires user attention?

[jkotas]

Yes, I think catching PlatformNotSupportedException should work just fine for this case.

[AaronRobinsonMSFT]

Suggestion for catching PlatformNotSupportedException is the recommendation here. There is a thought about adding something higher level RuntimeFeature.IsComSupported. Will close this specific issue in lieu of that link-ability issue.