.NET Framework test fails after updating to .NET 8 preview 5 SDK

[JamesNK]

Description

When I updated my repository to use .NET 8 preview 5 I got an error when running tests that target the .NET Framework.

Steps to reproduce

I have a PR that updates the repo to .NET 8: grpc/grpc-dotnet#2021

• Tests fail after updating to .NET 8 preview 5 - grpc/grpc-dotnet@47ae763 (#2021)
• Tests succeed after rolling back to .NET 8 preview 3 - grpc/grpc-dotnet@f903df4 (#2021)

Expected behavior

Tests pass.

Actual behavior

I see this error in logs:

System.TypeInitializationException: The type initializer for 'Microsoft.VisualStudio.TestPlatform.ObjectModel.EqtTrace' threw an exception. ---> System.TypeLoadException: Could not load type of field 'Microsoft.VisualStudio.TestPlatform.ObjectModel.PlatformEqtTrace:TraceSourceLevelsMap' (1) due to: Could not resolve type with token 01000019 from typeref (expected class 'System.Diagnostics.TraceLevel' in assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') assembly:System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 type:System.Diagnostics.TraceLevel member:(null)

2023-06-14T13:38:21.5328069Z Test run for /home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/bin/Release/net472/Grpc.Core.Api.Tests.dll (.NETFramework,Version=v4.7.2)
2023-06-14T13:38:21.6541094Z Microsoft (R) Test Execution Command Line Tool Version 17.7.0-preview.23272.5+6bce41dc77697d2c1f42ede74ee02458ff18e4c1 (x64)
2023-06-14T13:38:21.6542372Z Copyright (c) Microsoft Corporation.  All rights reserved.
2023-06-14T13:38:21.6669506Z 
2023-06-14T13:38:21.8004873Z Starting test execution, please wait...
2023-06-14T13:38:21.8374838Z A total of 1 test files matched the specified pattern.
2023-06-14T13:38:22.0083496Z Testhost process for source(s) '/home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/bin/Release/net472/Grpc.Core.Api.Tests.dll' exited with error: Unhandled Exception:
2023-06-14T13:38:22.0088289Z System.TypeInitializationException: The type initializer for 'Microsoft.VisualStudio.TestPlatform.ObjectModel.EqtTrace' threw an exception. ---> System.TypeLoadException: Could not load type of field 'Microsoft.VisualStudio.TestPlatform.ObjectModel.PlatformEqtTrace:TraceSourceLevelsMap' (1) due to: Could not resolve type with token 01000019 from typeref (expected class 'System.Diagnostics.TraceLevel' in assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') assembly:System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 type:System.Diagnostics.TraceLevel member:(null)
2023-06-14T13:38:22.0092088Z    --- End of inner exception stack trace ---
2023-06-14T13:38:22.0093505Z   at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main (System.String[] args) [0x00033] in <adaea5a299f34837b5c307dd5b21e834>:0 
2023-06-14T13:38:22.0096152Z [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Microsoft.VisualStudio.TestPlatform.ObjectModel.EqtTrace' threw an exception. ---> System.TypeLoadException: Could not load type of field 'Microsoft.VisualStudio.TestPlatform.ObjectModel.PlatformEqtTrace:TraceSourceLevelsMap' (1) due to: Could not resolve type with token 01000019 from typeref (expected class 'System.Diagnostics.TraceLevel' in assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') assembly:System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 type:System.Diagnostics.TraceLevel member:(null)
2023-06-14T13:38:22.0097683Z    --- End of inner exception stack trace ---
2023-06-14T13:38:22.0098258Z   at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main (System.String[] args) [0x00033] in <adaea5a299f34837b5c307dd5b21e834>:0 
2023-06-14T13:38:22.0098819Z . Please check the diagnostic logs for more information.
2023-06-14T13:38:22.0650563Z 
2023-06-14T13:38:22.0700889Z Test Run Aborted.
2023-06-14T13:38:22.0795140Z      1>Project "/home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/Grpc.Core.Api.Tests.csproj" on node 1 (VSTest target(s)).
2023-06-14T13:38:22.0797039Z      1>Project "/home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/Grpc.Core.Api.Tests.csproj" (1) is building "/home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/Grpc.Core.Api.Tests.csproj" (1:2) on node 1 (VSTest target(s)).
2023-06-14T13:38:22.0803297Z      1>VSTest:
2023-06-14T13:38:22.0803965Z          MSB4181: The "Microsoft.TestPlatform.Build.Tasks.VSTestTask" task returned false but did not log an error.
2023-06-14T13:38:22.0805148Z      1>Done Building Project "/home/runner/work/grpc-dotnet/grpc-dotnet/test/Grpc.Core.Api.Tests/Grpc.Core.Api.Tests.csproj" (VSTest target(s)) -- FAILED.

Diagnostic logs

Attached: net8p5-error.txt

Environment

[nohwnd]

Trying.

[nohwnd]

Ok so this seems to be running net472 tests on Linux. An they pass when 17.6.0-preview-20230223-05 is used, but not when 17.7.0-preview-23281-03+4ce2ff1f8 is used.

[JamesNK]

Is this scenario - .NET Framework tests running on Linux - a supported scenario, or was it an accident that it worked?

Do you know if this bug be fixed before .NET 8 is released? Right now, it is breaking this PR: grpc/grpc-dotnet#2021. I could disable the net472 tests on the build server to unblock. The disable could be temporary or permanent based on whether this will be fixed.

[nohwnd]

Still trying to figure this out.

[nohwnd]

We are constructing the .CLI package that we insert into dotnet sdk differently so we end up with a slightly newer version of System.Diagnostics.TraceSource.dll in the package than what we build with. This causes no issues on windows, but on Mono it matters.

[mrward]

Seeing what looks to be the same issue but with .NET 7.0.400 SDK installed, and running tests that target .NET Framework 4.6.1 and 4.7.2, on macOS with VS Mac, or from the command line with dotnet test.

Seems OK with .NET 7.0.307 SDK installed.

Would this also affect .NET 7.0.400?

[nohwnd]

Yes, 7.0.400 ships with 17.7 which has that bug, is that a big problem for you? We did not want to backport the change last minute because on Windows it works and there is a single report (now 2) of the issue.

[nohwnd]

backported in #4632

Inserted into sdk in dotnet/sdk#34383

Not sure when it will land into dotnet/installer, the last insertion I see there is from 2 weeks ago, probably because of branch lockdown dotnet/installer#16952 hopefully we see release/7.0.4xx update from dotnet/sdk in the PRs soon.