Target .NET Standard 2.1, .NET 6, .NET 8 only

[bjornharrtell]

No description provided.

[dbaileychess]

I like that we are moving forward to support the latest frameworks, but I do want to make sure we are not losing support. We support .NET Standard 2.0 and Framework 46 on nuget: https://www.nuget.org/packages/Google.FlatBuffers

[bjornharrtell]

@dbaileychess the problem is for how long do we support? Indefinitely is difficult. Will be even harder for new versions of .NET which has shorter support cycles than the older .NET Framework (which is difficult by itself since it is windows only).

[dbaileychess]

OK, thanks for improving it.

[bjornharrtell]

@dbaileychess FYI for Unity this means at least version 2021.2 AFAIK as of this change.

[ccorsano]

Hi, sorry to jump back on a closed topic !

Just adding a point that might have been missed in this initial conversation: dropping .netstandard2.0 removed the possibility to use Google.FlatBuffers and by extension Flatbuffers generated code when writing Source Generators, which is a very current use case in the .net ecosystem, especially in the context of writing AOT friendly code in .net 6 / .net 8 code.

I can see the strong incentive to consolidate around modern .net, but was there a compelling reason to drop .netstandard2.0 as well ?

[bjornharrtell]

I had no idea about this @ccorsano can you point me to where I can find out more? I don't think I have anything against adding back .net standard 2.0 but it surprises me that it would be a requirement.

[ccorsano]

Sure !
You can find more details about Source Generators here:
https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview

The netstandard2.0 requirement is mentioned in several highlights, and is definitely one of the pain point of an otherwise very nice feature.

I haven't seen any sign that it will be upgraded to netstandard2.1: it stayed netstandard2.0 despite source generators going through a couple major versions and seeing a growing usage in the community.

[bjornharrtell]

I see... however a bit confused about this comment dotnet/roslyn#47087 (comment).

Anyhow, I think we should try to add back netstandard2.0 target. I wonder if the NETSTANDARD2_1 macro is required though.

[ccorsano]

I see... however a bit confused about this comment dotnet/roslyn#47087 (comment).

Yes, I found that one and got confused as well ... I guess the reason for the netstandard2.0 constraint has to do with IDE support, and particularly Visual Studio.

Anyhow, I think we should try to add back netstandard2.0 target. I wonder if the NETSTANDARD2_1 macro is required though.

Sounds great !
I only skimmed through the changes, so I am not sure what the initial intention was with those #ifdef.
NETSTANDARD2.1 is only defined when targeting that framework, so I find the old code oddly specific.
With the upgrade to .net6 / .net8 reversing the condition with a NETSTANDARD2_0 could be a better option ?

[bjornharrtell]

@ccorsano I suggest we try to simply do #8295 first.