Some rules can no longer be silenced with an .editorconfig file in .NET 7 #6281
Comments
|
We're also running into this issue after udpating to Visual Studio 17.4 and .NET 7. While the projects configuration remained for "net6.0", the update in the tooling broke all our builds because we're using
and override errors within the .editorconfig instead of using other means of configuration. The official documentation at Is this a regression problem or has the behavior of this feature changed with .NET 7? |
|
This seems to have regressed with #5776 when I am not sure if it is possible to alter the compiler's precedence rules between Meanwhile, as a workaround you can do one of the following:
|
|
Solution 1 works, thanks! |
|
@mavasani thank you for locating/isolating the cause. As mentioned the two options are only workarounds and not a "solution" as @billybraga described it. Since there seems to be an open issue with the handling between .editorconfig and warnaserror arguments, should this topic then preferrably be left open since the regression is still an issue that may be fixed at some point? Or should this be adressed in a separate topic in an SDK repo? |
Can you please point out the issue? |
|
As you pointed out:
If I understand correctly, using compiler parameters is the necessary way to fix #5776 which implicitly changes the precedence of severity options and therefore I evaluated the behavior of
|
Fixes dotnet#6281 Prior implementation for `CodeAnalysisTreatWarningsAsErrors` passed `/warnaserror+:CAxxxx` to the command line for each CA rule ID. This led to couple of issues: 1. All disabled by default CA warnings seem to get enabled as errors 2. Editorconfig/globalconfig based configuration of the enabled CA rules stops working. The new implementation updates our globalconfig tooling to generate parallel globalconfigs with `_warnaserror` suffix, such that rules which would have had effective warning severity are set to error severity in the new globalconfig files. The targets/props that picks the appropriate globalconfig based on the `AnalysisLevel` property now chooses the file with `_warnaserror` suffix if user has enabled code analysis warnings to be treated as errors. Another note: Given that the buggy implementation of `CodeAnalysisTreatWarningsAsErrors` has already shipped in .NET7 and prior SDKs, we use a separate property `EffectiveCodeAnalysisTreatWarningsAsErrors`, so users using the newer NuGet package, but older .NET SDK can still get this functionality. Users that move to the newer .NET8 preview SDK with this fix can use `CodeAnalysisTreatWarningsAsErrors` itself.
Fixes dotnet#6281 Prior implementation for `CodeAnalysisTreatWarningsAsErrors` passed `/warnaserror+:CAxxxx` to the command line for each CA rule ID. This led to couple of issues: 1. All disabled by default CA warnings seem to get enabled as errors 2. Editorconfig/globalconfig based configuration of the enabled CA rules stops working. The new implementation updates our globalconfig tooling to generate parallel globalconfigs with `_warnaserror` suffix, such that rules which would have had effective warning severity are set to error severity in the new globalconfig files. The targets/props that picks the appropriate globalconfig based on the `AnalysisLevel` property now chooses the file with `_warnaserror` suffix if user has enabled code analysis warnings to be treated as errors. Another couple of notes: 1. Given that the buggy implementation of `CodeAnalysisTreatWarningsAsErrors` has already shipped in .NET7 and prior SDKs, we use a separate property `EffectiveCodeAnalysisTreatWarningsAsErrors`, so users using the newer NuGet package, but older .NET SDK can still get this functionality. Users that move to the newer .NET8 preview SDK with this fix can use `CodeAnalysisTreatWarningsAsErrors` itself. 2. I have adjusted the tooling to generate the config files into buildtransitive folder instead of build folder. This is needed as a follow-up to dotnet#6325 for globalconfig files to be correctly mapped. 3. I have also renamed all the tooling generated globalconfig files to have .globalconfig extension instead of .editorconfig extension, as that was misleading. I have verified that `CodeAnalysisTreatWarningsAsErrors` works fine with the locally built package when `EffectiveCodeAnalysisTreatWarningsAsErrors` is set to true. If I manually edit the targets/props shipped inside .NET7 SDK to delete all the prior shipped `CodeAnalysisTreatWarningsAsErrors` logic, then setting `CodeAnalysisTreatWarningsAsErrors` also works fine.
Fixes dotnet#6281 Prior implementation for `CodeAnalysisTreatWarningsAsErrors` passed `/warnaserror+:CAxxxx` to the command line for each CA rule ID. This led to couple of issues: 1. All disabled by default CA warnings seem to get enabled as errors 2. Editorconfig/globalconfig based configuration of the enabled CA rules stops working. The new implementation updates our globalconfig tooling to generate parallel globalconfigs with `_warnaserror` suffix, such that rules which would have had effective warning severity are set to error severity in the new globalconfig files. The targets/props that picks the appropriate globalconfig based on the `AnalysisLevel` property now chooses the file with `_warnaserror` suffix if user has enabled code analysis warnings to be treated as errors. Another couple of notes: 1. Given that the buggy implementation of `CodeAnalysisTreatWarningsAsErrors` has already shipped in .NET7 and prior SDKs, we use a separate property `EffectiveCodeAnalysisTreatWarningsAsErrors`, so users using the newer NuGet package, but older .NET SDK can still get this functionality. Users that move to the newer .NET8 preview SDK with this fix can use `CodeAnalysisTreatWarningsAsErrors` itself. 2. I have adjusted the tooling to generate the config files into buildtransitive folder instead of build folder. This is needed as a follow-up to dotnet#6325 for globalconfig files to be correctly mapped. 3. I have also renamed all the tooling generated globalconfig files to have .globalconfig extension instead of .editorconfig extension, as that was misleading. I have verified that `CodeAnalysisTreatWarningsAsErrors` works fine with the locally built package when `EffectiveCodeAnalysisTreatWarningsAsErrors` is set to true. If I manually edit the targets/props shipped inside .NET7 SDK to delete all the prior shipped `CodeAnalysisTreatWarningsAsErrors` logic, then setting `CodeAnalysisTreatWarningsAsErrors` also works fine.
|
Notes about this fix:
|
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
I'm trying a few changes to see if I can get the analyzers to behave properly locally. For some reason, they get into a state where they ignore the rules defined in the `.editorconfig` files entirely. Something similar to [this](dotnet/roslyn-analyzers#6281), but it certainly isn't "fixed". Also, I believe there is a case where the node reuse makes this even worse requiring me to kill all `dotnet` processes in order for some settings changes to even take effect, so I'm attempting the use of the `Directory.Build.rsp` file with the `/NodeReuse:false` setting to see if it helps at all. I have a feeling that there is a quirk between the nodes that VS starts up and the ones that the CLI starts up.
Analyzer
Diagnostic ID: CA1848:
Use the LoggerMessage delegates(among others)Analyzer source
SDK: Built-in CA analyzers in .NET 7 SDK
Version: SDK 7.0.100
Describe the bug
Some rules' severity can no longer be set to none with a global .editorconfig file in .NET 7, but it could in .NET 6.
Steps To Reproduce
Build this solution with .NET 7.
Expected behavior
The Net7ProjectWithEditorConfigIgnore project builds successfully, like its equivalent in .NET 6.
Actual behavior
The project Net7ProjectWithEditorConfigIgnore fails to build because of CA1848 (CA1303 was successfully silenced, as we can see by the fact that Net7ProjectWithoutEditorConfigIgnore fails with CA1303).
Additional context
See the .editorconfig. It sets to none the severity of CA1303 and CA1848 in the Net7ProjectWithEditorConfigIgnore folder.
The text was updated successfully, but these errors were encountered: