Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WarningLevel is no longer respected in .NET 5.0 #21599

Closed
waltdestler opened this issue Nov 10, 2020 · 4 comments · Fixed by #24826
Closed

WarningLevel is no longer respected in .NET 5.0 #21599

waltdestler opened this issue Nov 10, 2020 · 4 comments · Fixed by #24826
Assignees
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@waltdestler
Copy link

It appears that in .NET 5.0, the <WarningLevel> project property is no longer respected, and the project is always compiled at warning level 5 even if it is changed to something else. Changing back to .NET Core 3.1 fixes the issue.

Steps to reproduce:

  1. Create a new .NET 5.0 project. (My Visual Studio doesn't seem to yet have an option to create a .NET 5 project, so I created a .NET Core 3.1 project and changed to to .NET 5.0.)

  2. Replace the C# source code with the following:

using System;

namespace CSTest
{
	class Program
	{
		private static int Foo;

		static void Main()
		{
			Console.WriteLine(Foo);
		}
	}
}
  1. Compile it. As expected, you will receive the warning warning CS0649: Field 'Program.Foo' is never assigned to, and will always have its default value 0

  2. Try changing the warning level of the project to 3 (CS0649 is level 4, so 3 should hide the warning). My project file now looks like this:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <WarningLevel>3</WarningLevel>
  </PropertyGroup>

</Project>
  1. Compile again. Note that the warning is still shown. (This is the bug.)

  2. Change to .NET Core 3.1 and compile again. Note that the warning is no longer displayed, as was the original desire.

This behavior occurs regardless of whether I'm building using Visual Studio or running dotnet build from the command line. (Interestingly, when setting the warning level using Visual Studio via the Build tab in the project properties, sometimes the dropdown will immediately revert back to level 5, though Visual Studio does at least seem to consistently update the .csproj file itself.)

@AntonD228
Copy link

I have the same bug when migrating my NET Core 3.1 projects to .NET 5.
I investigated this problem and found this code in Microsoft.NET.Sdk.Analyzers.targets

    <!-- Compiler warning level, defaulted to 4. We promote it to 5 if the user has set analysis level to 5 or higher
         NOTE: at this time only the C# compiler supports warning waves -->
    <WarningLevel Condition="'$(Language)' == 'C#' And
                             '$(EffectiveAnalysisLevel)' != '' And
                             $([MSBuild]::VersionGreaterThanOrEquals($(EffectiveAnalysisLevel), '5.0'))">5</WarningLevel>

So, the workaround is that: Project properties -> Code Analysis -> Analysis Level and set it 'none'.
That's not a solution for me, but it could be useful for someone.

@dsplaisted dsplaisted transferred this issue from dotnet/sdk Sep 8, 2021
@mavasani
Copy link
Member

@jmarolf Doesn't this need a fix in dotnet/sdk?

@jmarolf
Copy link
Contributor

jmarolf commented Sep 30, 2021

yep this needs to be fixed in the sdk targets

@jmarolf jmarolf transferred this issue from dotnet/roslyn-analyzers Sep 30, 2021
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Sep 30, 2021
@Luuk34
Copy link

Luuk34 commented Nov 7, 2021

This devblog explains what is changed:
Automatically find latent bugs in your code with .NET 5

bkoelman pushed a commit to bkoelman/CSharpGuidelinesAnalyzer that referenced this issue Feb 2, 2022
…ault warning level depends on the target framework and is driven by the AnalysisLevel MSBuild property (see https://devblogs.microsoft.com/dotnet/automatically-find-latent-bugs-in-your-code-with-net-5/ and https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#analysislevel), which analyzers do not have access to by default (it would require user intervention as described at https://stackoverflow.com/questions/69215975/roslyn-codefix-msbuild-properties-metadata-and-unit-testing). So to get a good out-of-the-box experience, we'd need to duplicate the logic from Microsoft.NET.Sdk.Analyzers.targets, which only applies to SDK-style projects and is subject to change in each .NET release.

Setting the warning level to 9999 as recommended in https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings#warninglevel does not work anymore since .NET 5, because it gets overwritten at build time by Microsoft.NET.Sdk.Analyzers.targets (dotnet/sdk#21599).
renamorales309 added a commit to renamorales309/Guidelines-Analyzer-CSharp that referenced this issue Sep 23, 2022
…ault warning level depends on the target framework and is driven by the AnalysisLevel MSBuild property (see https://devblogs.microsoft.com/dotnet/automatically-find-latent-bugs-in-your-code-with-net-5/ and https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#analysislevel), which analyzers do not have access to by default (it would require user intervention as described at https://stackoverflow.com/questions/69215975/roslyn-codefix-msbuild-properties-metadata-and-unit-testing). So to get a good out-of-the-box experience, we'd need to duplicate the logic from Microsoft.NET.Sdk.Analyzers.targets, which only applies to SDK-style projects and is subject to change in each .NET release.

Setting the warning level to 9999 as recommended in https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings#warninglevel does not work anymore since .NET 5, because it gets overwritten at build time by Microsoft.NET.Sdk.Analyzers.targets (dotnet/sdk#21599).
brendasmith8 pushed a commit to brendasmith8/Guidelines-Analyzer-CSharp that referenced this issue Oct 18, 2022
…ault warning level depends on the target framework and is driven by the AnalysisLevel MSBuild property (see https://devblogs.microsoft.com/dotnet/automatically-find-latent-bugs-in-your-code-with-net-5/ and https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#analysislevel), which analyzers do not have access to by default (it would require user intervention as described at https://stackoverflow.com/questions/69215975/roslyn-codefix-msbuild-properties-metadata-and-unit-testing). So to get a good out-of-the-box experience, we'd need to duplicate the logic from Microsoft.NET.Sdk.Analyzers.targets, which only applies to SDK-style projects and is subject to change in each .NET release.

Setting the warning level to 9999 as recommended in https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings#warninglevel does not work anymore since .NET 5, because it gets overwritten at build time by Microsoft.NET.Sdk.Analyzers.targets (dotnet/sdk#21599).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants