Roslynator CLI Reports CS0121 on a .NET 9 Project (Visual Studio & dotnet build OK)

[fgimian]

Hey there, there's a very unusual issue with the Roslynator CLI whereby it reports CS0121 on valid .NET 9 code.

Simply create a new C# console application and replace the main program code with the following:

namespace Example;

internal class Program
{
    static void Main()
    {
        var text = string.Join(',', ["a", "b", "c"]);
        Console.WriteLine(text);
    }
}

Visual Studio shows no warnings:

The application builds:

~\source\Example via .NET v9.0.102 🎯 net9.0 took 4s
🕙 [ 04:03:53 PM ] ❯ dotnet build
Restore complete (0.5s)
  Example succeeded (2.8s) → bin\Debug\net9.0\Example.dll

Build succeeded in 3.6s

But the Roslynator CLI reports CS0121:

~\source\Example via .NET v9.0.102 🎯 net9.0
🕙 [ 04:03:40 PM ] ❯ roslynator.exe analyze .\Example.sln
Loading solution 'C:\Users\Fots\source\Example\Example.sln'...
Analyze solution 'C:\Users\Fots\source\Example\Example.sln'
Analyze 'Example' 1/1
  Program.cs(7,27): error CS0121: The call is ambiguous between the following methods or properties: 'string.Join(char, params ReadOnlySpan<object?>)' and 'string.Join(char, params ReadOnlySpan<string?>)'
Analyzed solution 'C:\Users\Fots\source\Example\Example.sln' (in 2.7 s)

1 CS0121

1 diagnostic found

Thanks heaps in advance!
Fotis

[josefpihrt]

The root cause of the issue is that .NET 9 is not used to build the solution (even if installed). I should see something like this when running the command with --verbosity diagnostic:

Roslynator Version: 0.10.0.0
Roslynator Target Framework: .NET Core
Roslyn Version: 4.11.0.0
Available MSBuild locations:
  .NET Core SDK, Version: 6.0.419, Path: /usr/local/share/dotnet/sdk/6.0.419
  .NET Core SDK, Version: 7.0.406, Path: /usr/local/share/dotnet/sdk/7.0.406
  .NET Core SDK, Version: 7.0.407, Path: /usr/local/share/dotnet/sdk/7.0.407
  .NET Core SDK, Version: 8.0.201, Path: /usr/local/share/dotnet/sdk/8.0.201
MSBuild location is '/usr/local/share/dotnet/sdk/8.0.201'

The issue has been fixed with #1622.