.NET 10: COM interop: IDispatchEx RCWs no longer support IReflect

[ClearScriptLib]

Description

In .NET 10, RCWs for COM objects that implement IDispatchEx no longer support IReflect. This regression has broken hundreds of our tests.

Reproduction Steps

using System.Reflection;
var file = Activator.CreateInstance(Type.GetTypeFromProgID("htmlfile"));
Console.WriteLine("IReflect is " + (file is IReflect ? "supported" : "NOT supported"));

Expected behavior

D:\Code\IReflectTest>dotnet run -f net9.0-windows
IReflect is supported

Actual behavior

D:\Code\IReflectTest>dotnet run -f net10.0-windows
IReflect is NOT supported

Regression?

Yes, as shown above, this is a regression. .NET 9 and earlier (and .NET Framework) work as expected.

Known Workarounds

Communicating with the object via IDispatch or IDispatchEx is possible but painful 😒

Configuration

No response

Other information

No response

[AaronRobinsonMSFT]

Upon reviewing, it looks like this is a behavioral change introduced in #105965. In that PR I noted the following:

The IReflect implementation can be removed since we missed a supporting type after we brought this back in dotnet/coreclr#21343. The supporting type is System.Runtime.InteropServices.ComTypes.IReflect, which is needed for it to work at all. Thus, this scenario has never worked in .NET Core.

This is true, but I missed the case where this type cast is handled through a QI for IDispatchEx. What this means it that the cast to IReflect will work, but calling any method on that interface will result in a TypeLoadException about an internal type. This was the behavior from .NET 5 until .NET 9. In .NET 10, we remove this mapping and now the cast to IReflect fails.

The only valid question that can be answered by casting to IReflect is "Does this COM object implement IDispatchEx?". This can be handled in a better way by doing the following:

var file = Activator.CreateInstance(Type.GetTypeFromProgID("htmlfile"));
Console.WriteLine("IDispatchEx is " + (file is IDispatchEx ? "supported" : "NOT supported")); 

[ComImport]
[Guid("A6EF9860-C720-11D0-9337-00A0C90DCAA9")]
interface IDispatchEx { }

@ClearScriptLib I'm inclined to simply follow this up with a breaking change notification with the above workaround. I can also make the IReflect cast continue to work and instead throw a reasonable exception when any API is called. If that is needed we can discuss it, but unless there is a strong business need a breaking change is the best we can do here.

[ClearScriptLib]

Hi @AaronRobinsonMSFT,

We've taken a closer look, and you're right. For historical reasons, our code performed the cast but did not invoke any IReflect members. The only regression in .NET 10 is that the cast fails, and we've already worked around it.

As for what to do about the regression, we defer to your expertise. Our only suggestion, should you decide not to restore the original functionality, would be that you update the IReflect documentation to make it clear that COM objects in .NET no longer implement that interface.

Thanks for your help!