Version 4.0.5 seems incompatible with .NET 6

[canon-cmre-benoit-lecardonnel]

Hi there,

We tried updating to version 4.0.5 of IDisposableAnalyzers, but get an error during dotnet build:

CSC : error CS9057: The analyzer assembly '....\.nuget\packages\idisposableanalyzers\4.0.5\analyzers\dotnet\cs\IDisposableAnalyzers.dll' references version '4.5.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. [....csproj]

This is with the most recent version of the .NET 6 SDK: v6.0.407.

With IDisposableAnalyzers 4.0.4, everything is fine.
Maybe something changed recently in this project? Unfortunately, I could not find a way to see the diff between 4.0.4 and 4.0.5.

[JohanLarsson]

What Visual Studio version are you using?

[canon-cmre-benoit-lecardonnel]

I'm using JetBrains Rider (2023.1) and also just the plain dotnet build command line from .NET SDK 6.0.407.

[JohanLarsson]

The error message suggests that the local tooling version is too low. Analyzer looks for 4.5.0 but most recent found is 4.3.0.
I don't remember between what versions I updated the roslyn dependency but updated recently to add support for newer features like records. Can probably roll back the dependency to 4.3.0 without it breaking anything but still interesting if an update on your side solves it.

[JohanLarsson]

It builds fine with latest version of Visual Studio

[canon-cmre-benoit-lecardonnel]

Indeed, I've just tried opening the same project in VS, and it works fine.
So I think it's only broken for CLI builds outside VS, when the project target .NET 6.0 or earlier.

We're running our build loop on Linux machines, so we cannot use VS there.
We also need to follow the latest LTS version of .NET, so our project targets .NET 6 only.

I tried running dotnet build while both .NET 6 and .NET 7 SDKs are installed, and get the same error. Not sure if there is a way to tell dotnet to leverage the .NET 7 SDK during the build of a .NET 6 project?

[JohanLarsson]

I don't think it is a framework issue but rather a tooling issue with compiler version.
For example the analyzer should analyze a net 3.5 project just fine.
From what I see it builds on both appveyor and devops for the projects I have updated.

[canon-cmre-benoit-lecardonnel]

I'll try to create a reproducer a bit later today, but just thought it would be worth mentioning that we restrict the project to a .NET 6 SDK by placing the following in global.json:

{
  "sdk": {
    "version": "6.0.0",
    "rollForward": "latestFeature"
  }
}

[JohanLarsson]

I guess I was too early updating version, probably better to lag a couple of versions to let tooling on build servers etc. catch up.
Checked off some chores as I have had so little time for this library lately.
Maybe rolling back the dependency is the best solution, no fun with tooling horror.

[canon-cmre-benoit-lecardonnel]

FWIW, here is a reproducer project: https://github.com/canon-benoit-lecardonnel/ReproIDisposableAnalyzers479

When writing this reproducer, I noticed that this issue is only reported as a warning by default. I had to enable TreatWarningsAsErrors to make it fail the build.
When TreatWarningsAsErrors is off, the build passes, but it stops reporting any issue with IDisposables (probably because it did not manage to load the analyzer).

I did not manage to make it work from the dotnet CLI (although I did not look for a long time). So it would be great to go back to a previous version indeed, especially since .NET 6 is still under active support by Microsoft until November 2024.

[JeremyMorton]

There is a way to use a specific compiler version, though you take on the responsibility of manual control of the compiler version this way, and this may stop working in the future; the package has disclaimers:

    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.5.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>

[prettybits]

I can report the same problem trying to use the newer versions and building on an Arch Linux installation directly via dotnet build. Targeting .NET 7 I have dotnet-sdk 7.0.103 available currently which ships the Roslyn compiler at version 4.4.0.0. I believe dotnet-sdk 7.0.2xx would ship with Roslyn 4.5.0.0, but the source build versions of the SDK generally used by Linux distributions can only build 1xx variants to the best of my knowledge. dotnet-sdk-6.0 (6.0.114) ships with compiler version 4.0.0.0 for what it's worth.

The official SDK download page lists the Visual Studio support versions as "Visual Studio 2022 (v17.4)" and "Visual Studio 2022 (v17.0)" respectively.

[SeMuell]

There is a way to use a specific compiler version, though you take on the responsibility of manual control of the compiler version this way, and this may stop working in the future; the package has disclaimers:

    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.5.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>

This solution unfortunately does not work for us with dotnet format. The only way we could get it running on dotnet-sdk 7.0.203 is using the older version 4.0.4.

[SeMuell]

Issue is related to dotnet/sdk#32598 and dotnet/format#1546
Since the most recent SDK update 7.0.304 I can confirm that it is fixed.