Add support for the .NET 8 SDK

[0xced]

Downgrading Microsoft.CodeAnalysis.CSharp from version 4.13.0 to 4.11.0 enables using Zomp.SyncMethodGenerator with the .NET 8 SDK at the very small price of using nameof(Nullable<int>.*) instead of nameof(Nullable<>.*)

Currently, using Zomp.SyncMethodGenerator with the .NET 8 SDK fails with this error.

error CS9057: The analyzer assembly 'Zomp.SyncMethodGenerator.dll' references version '4.13.0.0' of the compiler, which is newer than the currently running version '4.11.0.0'.

[virzak]

What do the brackets mean?

[0xced]

It means exact version match, see the NuGet Package versioning - Version ranges documentation. This ensures that version 4.11.0 will be resolved if another package depends on Microsoft.CodeAnalysis.CSharp.

[virzak]

I installed .NET SDK 8.0 on a VM and indeed there was a compilation error. When I rolled back to 4.11.0.0 everything worked. I don't think you need any changes other than the ones in Directory.Packages.props. Everything will compile into .NET Standard and the latest syntax to be used will be the latest C#.

[0xced]

Yes that's true. But having a global.json file that forces to use the .NET 8 SDK makes it easy to ensure that Zomp.SyncMethodGenerator will work with the .NET 8 SDK thanks to the GenerationSandbox.Tests project.

If you prefer to use the .NET 9 SDK that's fine, the global.json file can be removed and the modifications from nameof(Nullable<>.*) to nameof(Nullable<int>.*) can be reverted.

[virzak]

Do you have global.json in your consuming project? One concern that I have is if this project uses old assemblies, it will not be able to accommodate new language features in a timely manner. For example, C# 14 extensions require Microsoft.CodeAnalysis.CSharp version 5.*.

If this library makes a commitment to support .NET 8 SDK, we'll have to be on that version until November 10, 2026

[0xced]

Do you have global.json in your consuming?

Actually the .NET 9 SDK is not even installed on the build machine.

One concern that I have is if this project uses old assemblies, it will not be able to accommodate new language features in a timely manner.

I have removed the global.json and restored the use of nameof with unbound generic in the AsyncToSyncRewriter class. So now the .NET 8 SDK becomes supported but without holding back anything.

[virzak]

It does hold back upgrading to latest version of C#. This is a problem even your issue never came up.

In #94 I must upgrade to 5.x in order to support latest C# 14 extensions, but that will fail everyone who doesn't have .NET 10 SDK on their build server.

There are a few options here:

One is to have 1-3 versions of the library at all times. They would be targeting SDKs which didn't reach end of support yet.
Another - and I'd have to test if it even works, but perhaps the analyzer doesn't have to depend on the compiler which comes with Visual Studio. Perhaps there's a way to include Microsoft.Net.Compilers.Toolset like we had to do when C# 14 extension came out, but Visual Studio didn't support it yet.

I would definitely prefer a solution which can parse code without relying on the installed SDK.

[virzak]

I don't think that a source generator should be a driver of which SDK to use, but just out of curiosity, why don't you have .NET 9 SDK on the build server?

[0xced]

In #94 I must upgrade to 5.x in order to support latest C# 14 extensions, but that will fail everyone who doesn't have .NET 10 SDK on their build server.

OK, I did not realise that you had to upgrade to Microsoft.CodeAnalysis.CSharp 5 in the source generator itself. But of course it makes sense that you need it to support the new C# 14 extensions.

I would suggest to release a new version using Microsoft.CodeAnalysis.CSharp version 4.11.0 instead of 4.13.0 in order to support the .NET 8 SDK. Then when the .NET 10 SDK is released, a new version of Zomp.SyncMethodGenerator can be released, targeting Microsoft.CodeAnalysis.CSharp version 5.0.0 and thus working for the .NET 10 SDK only.

People can choose to use an older version if they want support for the .NET 8 SDK and use th newer version if they need support for the .NET 10 SDK. What do you think?

I would definitely prefer a solution which can parse code without relying on the installed SDK.

Hmmm, the source generator will always use the Microsoft.CodeAnalysis.CSharp package from the SDK. The PackageReference for Microsoft.CodeAnalysis.CSharp in the csproj has PrivateAssets="all". So at runtime, Microsoft.CodeAnalysis.CSharp comes from the SDK.

You can do this to see exactly what happens.

var assembly = typeof(CSharpSyntaxRewriter).Assembly;
spc.AddSource(source.Path, SourceText.From(source.Content + $"// **DIAGNOSE** {assembly} at {assembly.Location}", Encoding.UTF8));

Sure enough, by enabling EmitCompilerGeneratedFiles in the project that consumes Zomp.SyncMethodGenerator file we can confirm that the Microsoft.CodeAnalysis.CSharp assembly used is the one from the SDK after looking in the generated files.

// **DIAGNOSE** Microsoft.CodeAnalysis.CSharp, Version=4.14.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 at /usr/local/share/dotnet/sdk/9.0.300/Roslyn/bincore/Microsoft.CodeAnalysis.CSharp.dll

I don't think that a source generator should be a driver of which SDK to use, but just out of curiosity, why don't you have .NET 9 SDK on the build server?

We use Long Term Support (LTS) releases and .NET 9 is under Standard Term Support (STS). 🤷🏻‍♂️

[virzak]

No problem going with this solution for now. I'll try to include Microsoft.CodeAnalysis.CSharp in the nuget package, so that perhaps it is used over the VS version.

[0xced]

I'll try to include Microsoft.CodeAnalysis.CSharp in the nuget package, so that perhaps it is used over the VS version.

Here be dragons. 🐉

Thanks for merging, another pull request is coming soon! 😉