Visualstudio-docs: EnableNETAnalyzers for pre 5.0 does not work

Created on 5 Feb 2021  Â·  5Comments  Â·  Source: MicrosoftDocs/visualstudio-docs

The linked doc states that "You can enable code analysis on projects that target earlier .NET versions by setting the EnableNETAnalyzers property to true."

Given this code:

    public class Class1
    {
        public Class1(string bob)
        {
            Console.WriteLine(bob.ToString());
        }
    }

And this csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
    <AnalysisMode>AllEnabledByDefault</AnalysisMode>
  </PropertyGroup>
</Project>

dotnet build will give:

warning CA1062: In externally visible method 'Class1.Class1(string bob)', validate parameter 'bob' is non-null before using it. If appropriate, throw an ArgumentNullException when the argument is null or add a Code Contract precondition asserting non-null argument. [C:\code\CA1062Test\CA1062Test.csproj]

Make this one change to .csproj:

<TargetFramework>netcoreapp3.1</TargetFramework>

then you get no build warnings.

For completeness, this .csproj will also not give any build warnings:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AnalysisMode>AllEnabledByDefault</AnalysisMode>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="5.0.3">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>
</Project>

For reference:

C:\code\CA1062Test> dotnet --list-sdks
3.1.404 [C:\Program Files\dotnet\sdk]
5.0.101 [C:\Program Files\dotnet\sdk]


Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Pri1 doc-bug visual-studio-windowprod vs-ide-code-analysitech

Most helpful comment

Manish, is the AnalysisLevel element required to make the scenario work?

There was a bug in .NET 5.0 SDK that required AnalysisLevel to be set when using NuGet package, but this should be fixed with 5.0.2 release of the SDK.

All 5 comments

@flytzen As a workaround you can edit your netcore 3.1 .csproj to add AnalysisLevel and the package ref, e.g.:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <!-- <TargetFramework>net5</TargetFramework> -->
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AnalysisLevel>latest</AnalysisLevel>
    <AnalysisMode>AllEnabledByDefault</AnalysisMode>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="5.0.3" />
  </ItemGroup>
</Project>

As you noted, the doc states:

You can enable code analysis on projects that target earlier .NET versions by setting the EnableNETAnalyzers property to true.

That doesn't seem to work. But the docs here https://github.com/dotnet/roslyn-analyzers#microsoftcodeanalysisnetanalyzers

For projects targeting earlier .NET frameworks, you can enable them in your MSBuild project file by setting one of the following properties:

  1. EnableNETAnalyzers
  2. AnalysisLevel

I could only get the latter to work :(

@mavasani Manish, is the AnalysisLevel element required to make the scenario work?

On my projects I got mine to work by setting:

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<EnableNETAnalyzers>true</EnableNETAnalyzers>
<AnalysisLevel>preview</AnalysisLevel>
<AnalysisMode>AllEnabledByDefault</AnalysisMode>

And then telling the users who want to use my projects and build them to install the .NET 6 SDK on from the master branch so that it works.

And on my projects they target net5.0;net5.0-windows;net40;net45;net461;netcoreapp2.0;netcoreapp3.0;netcoreapp3.1;netstandard2.0;netstandard2.1.

I also use analyzers like IDisposable, SecurityCodeScan, StyleCop, etc that I hope will eventually get merged into the built in analyzer sometime in the future as well too.

It would also be great if there was also an analysis rule for when you target an version of any framework assembly/package that is vulnerable to things like RCE (Remote Code Execution), XML Injection, etc too so that way the assembly would get updated quickly on my code too, that or drop an older TFM that is vulnerable to issues like that.

Manish, is the AnalysisLevel element required to make the scenario work?

There was a bug in .NET 5.0 SDK that required AnalysisLevel to be set when using NuGet package, but this should be fixed with 5.0.2 release of the SDK.

Manish, is the AnalysisLevel element required to make the scenario work?

There was a bug in .NET 5.0 SDK that required AnalysisLevel to be set when using NuGet package, but this should be fixed with 5.0.2 release of the SDK.

That is true, but then sometimes people use things which is bugged even on the latest stable 5.0.x release so then you are forced to use the .NET 6 SDK in the meantime (until it gets fixed), I face that issue on my end as well, but thank god my github actions workflows that use the 5.0.3 SDK do not build error at least.

However I would like to find out if I could technically tell github actions to use preview SDKs that can only be accessed by aka.ms links inside of the readmeto dotnet/installer. That will have to be an experiment on my end later.

In my case the bug is related to nuget restore on it confusing the packages to .net 5, with my .net 5-windows target and the windows one overwriting the one for non-windows 👀 which oddly does not happen on the .NET 6 SDK.

Was this page helpful?
0 / 5 - 0 ratings