Test build failure: The type 'EventPipeProvider' is defined in an assembly that is not referenced

[BruceForstall]

In a build of the Pri-1 tests:

https://dev.azure.com/dnceng/public/_build/results?buildId=1640719&view=logs&j=db768a9e-3325-5ce3-2d52-896c40bee68a&t=59112ad9-fe58-56ee-6943-84df6f0e3f8e

    eventsourceerror -> /__w/1/s/artifacts/tests/coreclr/AnyOS.x64.Checked/tracing/eventpipe/eventsourceerror/eventsourceerror/eventsourceerror.dll
/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1.cs(24,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1.csproj] [/__w/1/s/src/tests/build.proj]
##[error]src/tests/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1.cs(24,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1.csproj]
/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCEvents.cs(25,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCEvents.csproj] [/__w/1/s/src/tests/build.proj]
##[error]src/tests/tracing/eventpipe/eventsvalidation/GCEvents.cs(25,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCEvents.csproj]
/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCFinalizers.cs(25,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCFinalizers.csproj] [/__w/1/s/src/tests/build.proj]
##[error]src/tests/tracing/eventpipe/eventsvalidation/GCFinalizers.cs(25,20): error CS0012: The type 'EventPipeProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Diagnostics.NETCore.Client, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. [/__w/1/s/src/tests/tracing/eventpipe/eventsvalidation/GCFinalizers.csproj]

A rolling outerloop job will presumably hit this soon:

https://dev.azure.com/dnceng/public/_build/results?buildId=1640881&view=logs&j=db768a9e-3325-5ce3-2d52-896c40bee68a

It seems likely this is related to #64358

@mdh1418 @hoyosjs

[BruceForstall]

@dotnet/dotnet-diag This is breaking test builds

[hoyosjs]

I'll try to take a look in a bit

[mdh1418]

In https://github.com/dotnet/runtime/pull/64358, I had removed the test_dependencies for Microsoft.Diagnostics.NETCore.Client and instead used the updated source ported over for a number of tests, including it in common.csproj.
I missed this, I think because the lane was not ran on the PR that was merged (how can a situation like this be avoided in the future?)

The change is that the project references common.csproj, which uses Microsoft.Diagnostics.NETCore.Client in tree. I think the fix would be to update this project similar to 3babfc2.

Just put up a PR that should fix it, thank you for discovering!

[hoyosjs]

You can't, at least not easily/cheaply - those pipelines are outterloop because they are prohibitively expensive to run on every change. If you see a CLRPriority=1 test that gets touched by a change, then you request them. This is more of a "It's search and go through dependencies more than automation" type of deal right now. I was thinking maybe having the PR build priority1 would guard against this, but I am not sure this breaks often enough to justify the +30 mins in time for every PR. In this case, changing common touches all possible tests - you just need to make sure no tests that use it are Pri1. I missed this in the review, so that's my bad. It's not always easy to catch these things; thanks for the quick fix :)