Disable ComInterfaceGenerator.Unit.Tests for NativeAOT

[MichalStrehovsky]

Fixes#77476.

The project is set up in an odd way and we miss a reference. This happens in a spot that is hard to be proactive about: the missing type is a generic argument and that's annoying to check for because it could lead to recursions that we're not ready to handle - e.g. class Foo : IComparable<Foo>. We could fix that, but also the detection of broken inputs has its limits.

Also, building a test that references Roslyn takes forever and source generator tests are unlikely to find runtime issues so I'm 100% comfortable not running this test ever.

Cc @dotnet/ilc-contrib

[MichalStrehovsky]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MichalStrehovsky]

I'm also blocking ComInterfaceGenerator.Tests because DNNE doesn't work.

Cc @dotnet/interop-contrib - we won't have any NativeAOT coverage for this unless a non-DNNE fallback is added.

00 00007eec`c052cca0 00007f2d`581ab535 libc_2_28!gsignal+0x10b
01 00007eec`c052cdc0 00007eec`beccb67b (T) libc_2_28!abort+0x121
02 00007eec`c052cef0 00007eec`beccb432 Microsoft_Interop_Tests_NativeExportsNE!get_fast_callable_managed_function+0x26
03 00007eec`c052cf00 00007eec`beccb4a9 Microsoft_Interop_Tests_NativeExportsNE!preload_runtime+0x3a2
04 00007eec`c052d350 00007eec`beccb043 Microsoft_Interop_Tests_NativeExportsNE!get_callable_managed_function+0x49
05 00007eec`c052d5c0 000055fc`4f7d599d Microsoft_Interop_Tests_NativeExportsNE!new_native_object+0x23
06 00007eec`c052d5d0 000055fc`4f7d5062 ComInterfaceGenerator!ComInterfaceGenerator_Tests_ComInterfaceGenerator_Tests_NativeExportsNE_ImplicitThis___NewNativeObject_g____PInvoke_4_0+0x2d [/_/src/libraries/System.Runtime.InteropServices/tests/ComInterfaceGenerator.Tests/Microsoft.Interop.LibraryImportGenerator/Microsoft.Interop.LibraryImportGenerator/LibraryImports.g.cs @ 20] 07 00007eec`c052d630 000055fc`4f94db37 ComInterfaceGenerator!ComInterfaceGenerator_Tests_ComInterfaceGenerator_Tests_ImplicitThisTests__ValidateImplicitThisFunctionCallsSucceed+0x12 [/_/src/libraries/System.Runtime.InteropServices/tests/ComInterfaceGenerator.Tests/ImplicitThisTests.cs @ 70] 

[MichalStrehovsky]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AaronRobinsonMSFT]

I'm also blocking ComInterfaceGenerator.Tests because DNNE doesn't work.

I don't understand why DNNE doesn't work in this case. If the test is NativeAOT, DNNE should be able to load an instance of the runtime and carry on. Is understanding why that is failing in NativeAOT the issue?

[MichalStrehovsky]

I'm also blocking ComInterfaceGenerator.Tests because DNNE doesn't work.

I don't understand why DNNE doesn't work in this case. If the test is NativeAOT, DNNE should be able to load an instance of the runtime and carry on. Is understanding why that is failing in NativeAOT the issue?

I didn't debug this but how does dnne find a CoreCLR runtime if there's no runtime loaded in the process?

[AaronRobinsonMSFT]

I didn't debug this but how does dnne find a CoreCLR runtime if there's no runtime loaded in the process?

It uses the normal .NET hosting look up. In this case it uses the dropped .runtimeconfig.json next to the managed assembly. It will also respect DOTNET_ROOT as well. @elinor-fung or @vitek-karas will know if there are other mechanisms.

[MichalStrehovsky]

I didn't debug this but how does dnne find a CoreCLR runtime if there's no runtime loaded in the process?

It uses the normal .NET hosting look up. In this case it uses the dropped .runtimeconfig.json next to the managed assembly. It will also respect DOTNET_ROOT as well. @elinor-fung or @vitek-karas will know if there are other mechanisms.

I don't think we have a globally installed .NET runtime when doing NativeAOT testing. Helix machines are unlikely to have it and we don't send anything in the payload either because we're testing NativeAOT.

[AaronRobinsonMSFT]

I see. What we might want to do then NativeAOT these assets instead of using DNNE for the NativeAOT scenario. This way we would get additional testing and since DNNE uses the same export tech as NativeAOT, I think it should just work.