@dagood This seems to be failing because of dotnet/core-setup#6096 and related changes. Could you please take a look?

@jkotas I think this would actually be caused by dotnet/core-setup#5893: Microsoft.NETCore.App is now Microsoft.NETCore.App.Internal, but the SDK only knows about the old name. The new Microsoft.NETCore.App doesn't contain any refs or pull in any runtimes, which would cause the compilation errors I'm seeing in this CI.

(dotnet/core-setup#6096 actually brings us one step back to how things were, by renaming runtime.<rid>.Microsoft.NETCore.App.Internal to runtime.<rid>.Microsoft.NETCore.App. That wasn't enough to fix CoreCLR tests, though, apparently.)

The way I fixed this for Core-Setup tests was to include an explicit Microsoft.NETCore.App.Internal reference in all 3.0 test projects:
https://github.com/dotnet/core-setup/blob/df68c22252186540d31c8b869109580330fd6293/src/test/Assets/TestProjects/MNADeprecationWorkaround.props
(CoreCLR'd use MicrosoftNETCoreAppVersion instead of MNAVersion.)

There might be a better way. I'm not sure if there are other SDK features with the implicit reference you'd miss by using that method. CoreCLR tests are undoubtedly more complex than Core-Setup's.
/cc @dsplaisted

@jkotas I think what you should do here is probably to update to a later version of the .NET Core SDK, which will implicitly reference the .Internal package, rather than modifying the test project you are creating.

I think what you should do here is probably to update to a later version of the .NET Core SDK, which will implicitly reference the .Internal package, rather than modifying the test project you are creating.

What version enables this? Source-build constraints mean we should use at most 3.0 Preview 5 in master.

update to a later version of the .NET Core SDK, which will implicitly reference the .Internal package

We are not on 3.0 SDK yet. It is a project on its own that I expect will take a while to finish. @AaronRobinsonMSFT #24285 is working towards it.

We can wait for the SDK update for this, but I am not sure whether the stale version of NETCoreApp used by CoreCLR is going to bite us somewhere else.

cc @jeffschwMSFT @RussKeldorph

We've made a bunch of changes to how projects are built in .NET Core 3.0. It's going to be increasingly difficult to get a project to build correctly using a previous version of the SDK.

In this case it looks like possibly you need to apply the same fix to Coreclr.TestWrapper.csproj, but it's hard to tell.

@dsplaisted @dagood @jkotas I am very much out of my comfort zone here so can I get someone to elaborate a bit on the root issue. As @jkotas mentioned my PR is a small step toward 3.0 SDK support, but right now is only moving toward SDK support but still targeting 2.1. What is the issue here that relies on the semantics defined in 3.0?

Spoke to @dsplaisted offline. I understand this issue now.

@AaronRobinsonMSFT what do we need to do to get this in?

We need to move over to SDK projects and adopt the 3.0 SDK. From my understanding this is blocked until that point. I am hitting a single test failure on Ubuntu CoreFX Checked and trying to figure out the issue. Until that happens step 0 - convert to SDK projects can't happen. Once that is done, someone can try moving to 3.0, which should be a relatively simple transition.

cc @RussKeldorph

We should not wait for @AaronRobinsonMSFT to finish #24285 to unblock this. We need to apply a workaround, such as suggested by @dagood or @dsplaisted, if we can't temporarily back out whatever change originally caused this in core-setup or other repo.

@josalem Can you see if you can figure this out?

I think I've got a workaround that works locally, but I want to test it against all platforms to make sure it unblocks things.

The failures for ARM, ARM64, and OSX look to be related to dotnet/core-eng#6266

/azp run Test Pri0 Linux arm64_checked
/azp run Test Pri0 Linux arm_checked
/azp run Test Pri0 OSX x64_checked

No pipelines are associated with this pull request.

/azp list

CI/CD Pipelines for this repository:
coreclr-outerloop
coreclr-ci
dotnet-coreclr-nullablefeature

last failure looks related to: dotnet/core-eng#6295

Conflict in the saved pipeline artifacts. Closing and reopening.

Something seems wonky about the Windows legs of CI. I can't seem to find the current run of CI in the checks details or on Az Pipelines. The Linux arm pri0 tests are passing now according to Az Pipelines now though.

Took the latest version when merging the file.