SystemException constructor is obsoleted in .NET 8. Add [Obsolete] attributes to the constructors which depend on it.
Fix reference related error (CS8347)

LangVersion

IfTargetFramework isnet8.0 thenLangVersion is12 else as-is.

pCYSl5EDgo added9 commits

January 10, 2024 08:38

update global.json to 8.0.100

8cca53a

Fix: secutiry vulnerability in Nuget.Protocol 6.5.0

60ac95f

GHSA-6qmf-mmc7-6c2p

Update packages which does not need code fix

787ed74

Update docker file dependency

f3e6307

update StleyCop.Analyzers.Unstable to 1.2.0.556

11cf2f0

suppress SA1402

Update TargetFrameworks

663338e

SystemException(SerializationInfo, StreamingContext) is now oboslete

7fc36c9

fix warning: in paramter

6d409ba

fix error: ref scope problem

5177513

pCYSl5EDgo mentioned this pull request

Jan 10, 2024

Update to .NET 8#1725

Open

14 tasks

pCYSl5EDgo changed the title~~.Net 8 Update: TargetFrameworks~~.Net 8 Update(2): TargetFrameworks

Jan 10, 2024

ref readonly parameter requires C#12

d11f14a

pCYSl5EDgo closed this

Jan 10, 2024

pCYSl5EDgo added2 commits

January 10, 2024 20:49

support net80 reference assembly in roslyn testing

62619bd

downgrade

9a5da8b

pCYSl5EDgo reopened this

Jan 10, 2024

Copy link

ContributorAuthor

pCYSl5EDgo commentedJan 10, 2024•
edited
Loading

I can build the solution and all tests are passed in dotnet CLI.
But in Visual Studio 17.8.4, the build process fails atMessagePack.GeneratedCode.Tests (Edit: Sorry, notat butrelated tosandbox/SharedData.)
What is happening in Visual Studio?

Remove unnecessary warning restore

17adbee

AArnott approved these changes

Jan 10, 2024

View reviewed changes

Copy link

Collaborator

AArnott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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 failurein 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.csShow resolvedHide resolved

AArnott reviewed

Jan 10, 2024

View reviewed changes

Copy link

Collaborator

AArnott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

One link of the chain that explains why build in VS fails is that theGeneratedMessagePackResolver type inSandbox andSharedData is being generated asinternal instead ofpublic, making it inaccessible to theMessagePack.GeneratedCode.Tests project.

AMessagePackAnalyzer.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.

Copy link

ContributorAuthor

pCYSl5EDgo commentedJan 10, 2024

Thank you for your investigating.
Oh... They are generated asinternal... I missed it.

AArnott reviewed

Jan 10, 2024

View reviewed changes

Copy link

Collaborator

AArnott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.