NativeAOT Fix error during unwrap existing instance

[kant2002]

If element in the cache, properly return success creation status

[ghost]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

If element in the cache, properly return success creation status

Author:	kant2002
Assignees:	-
Labels:	area-System.Runtime.InteropServices
Milestone:	-

[AaronRobinsonMSFT]

Do we have a test for this? I assume we can use the one we have for CoreCLR, but don't run that on NativeAOT at the moment. @MichalStrehovsky is that fair?

[kant2002]

We seems to be have Smoke tests which similar to scenario where I hit this bug.

runtime/src/tests/nativeaot/SmokeTests/ComWrappers/ComWrappers.cs

Line 106 in 75fb632

public static void TestRCWRoundTripRequireUnwrap()

I think this tests should catch this

runtime/src/tests/Interop/COM/ComWrappers/API/Program.cs

Line 179 in 75fb632

static void ValidateCreateObjectCachingScenario()

And this test was enabled in runtimelab. So I'm puzzled a bit.

[kant2002]

To be precise. My scenario was

cw.GetOrCreateObjectForComInstance(ptr, CreateObjectFlags.None);
cw.GetOrCreateObjectForComInstance(ptr, CreateObjectFlags.Unwrap);

[MichalStrehovsky]

Do we have a test for this? I assume we can use the one we have for CoreCLR, but don't run that on NativeAOT at the moment. @MichalStrehovsky is that fair?

Yes, eventually we should run all the Pri-0 interop tests in the CI. I'm standing up more of the CI as I'm typing this.

[MichalStrehovsky]

The NativeAOT arm64 failures are unrelated. I think I'll need to pull the NativeAOT ARM64 testing until the issues are root caused. Lucky for me, it found an infra issue where the ARM64 machines are not configured to collect dumps, so can't even get a dump out of this :(.