.NET 8 Update(2): TargetFrameworks#1728
Conversation
suppress SA1402
|
I can build the solution and all tests are passed in dotnet CLI. |
AArnott
left a comment
There was a problem hiding this comment.
Thanks for working on these changes. They all look good.
in Visual Studio 17.8.4, the build process fails at sandbox/SharedData.
I'm not seeing the failure in that project. But I do see a build failure in MessagePack.GeneratedCode.Tests when it runs from visual studio (CLI is fine, as you say). I'll look into this and loop in the roslyn team if I suspect a compiler bug.
src/MessagePack.UnityClient/Assets/Scripts/Tests/ShareTests/MessagePackBinaryTest.cs
Show resolved
Hide resolved
AArnott
left a comment
There was a problem hiding this comment.
One link of the chain that explains why build in VS fails is that the GeneratedMessagePackResolver type in Sandbox and SharedData is being generated as internal instead of public, making it inaccessible to the MessagePack.GeneratedCode.Tests project.
A MessagePackAnalyzer.json file for each of these projects specify that this resolver should be produced publicly. And indeed, dotnet build honors this. But the VS build doesn't.
I'll keep investigating.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
|
Thank you for your investigating. |
AArnott
left a comment
There was a problem hiding this comment.
I found the problem. Our in-solution .props file for activating the source generator is missing a few dependencies, causing the in-VS build to fail to deserialize the json file, and when it fails to do that, it just swallows it and proceeds with default behavior. Not great on multiple levels. I'm preparing a fix now.
|
Thank you! |
AArnott
left a comment
There was a problem hiding this comment.
Thank you very much for preparing these changes!
TargetFramework Changes
net6.0->net6.0andnet8.0net7.0->net8.0Code Fixes
LangVersion
If
TargetFrameworkisnet8.0thenLangVersionis12else as-is.