Suppressing one IDExxxx rule from a multi-rule EditorConfig setting is not possible if EnforceCodeStyleInBuild is enabled

[cremor]

Suppressing one IDExxxx rule from a multi-rule EditorConfig setting is not possible if EnforceCodeStyleInBuild is enabled

[sharwell]

Is this difference expected?

It's not desired, but it's a situation we know happens. We are working on a solution in dotnet/sdk#41791.

[sharwell]

This behavior is by design. We are working (#73843) to add an option where the :warning suffix on dotnet_style_prefer_collection_expression is ignored in favor of using the value from dotnet_diagnostic.IDE0305.severity, but this option will not apply to individual rules (you either get the :warning suffix support on all supported code style rules, or you do not get it at all).

I would recommend filing a bug report specifically for the dotnet_style_prefer_collection_expression if its current configuration is problematic.

[sharwell]

@cremor Thank you very much for taking the time to file this issue with the full detail. It would have taken me a very long time to otherwise unravel this slightly different situation from the others that have been reported recently.

I'm going to keep it in its current form so we can continue to point to it in the future as the reason why code style settings should in general apply to only one diagnostic. The new issue would focus on dotnet_style_prefer_collection_expression specifically and its impact on multiple diagnostic IDs.

[cremor]

@sharwell I'm not sure if I understand you correctly.

Build time analysis - which was only enabled for the :severity suffix syntax in #52991 for .NET 9 (AnalysisLevel 9) - might not support this case. Ok, that could be a known limitation (which should be documented).

But are you saying that the current behavior of the IntelliSense analysis is by design too? Should the property EnforceCodeStyleInBuild really influence IntelliSense analysis?

[sharwell]

@cremor I don't think I understand the question. I was reviewing this issue for the limited case where EnforceCodeStyleInBuild is set to true (step 4 in the initial post). Is there a separate question you have for a scenario where it is set to false?

[cremor]

No, my question is about when it is set to true. But I'm observing the IntelliSense analysis results in the Visual Studio error list. I'm not concerned about build time analysis output (right now).
So while I have set EnforceCodeStyleInBuild to true (for unrelated reasons), it shouldn't affect IntelliSense analysis results in my opinion.

[cremor]

@sharwell (Again using a mention, not sure if you saw my last message.)

I have an additional question. What did you mean with this?

I would recommend filing a bug report specifically for the dotnet_style_prefer_collection_expression if its current configuration is problematic.

Did you only mean that in the context of build time analysis, or for IntelliSense analysis too?

[sharwell]

No, my question is about when it is set to true. But I'm observing the IntelliSense analysis results in the Visual Studio error list. I'm not concerned about build time analysis output (right now).

My answer above was related to what happens on build when EnforceCodeStyleInBuild is true. If this value is causing a difference in the IDE or some other scenario, I would need to see a description of scenario A and the behavior in scenario A, and a description of scenario B and the behavior in scenario B. At that point we can figure out why the behavior changes.

The EnforceCodeStyleInBuild setting should only impact IntelliSense behavior for the purpose of making the IDE behavior be the same as the compile-time behavior. Sometimes when this option is false, the IDE does things that the build would not do.

Did you only mean that in the context of build time analysis, or for IntelliSense analysis too?

I'm not aware of a case where it would make a difference here.

[cremor]

If this value is causing a difference in the IDE or some other scenario, I would need to see a description of scenario A and the behavior in scenario A, and a description of scenario B and the behavior in scenario B. At that point we can figure out why the behavior changes.

@sharwell The description is this issue. If I understand you correctly then scenario A is step 3 and scenario B is step 5 of my first post here.

[ToddGrun]

@sharwell -- Can this be assigned to you for further follow up?

[ToddGrun]

Going to go ahead and assign to Sam

[cremor]

Since this was reopened, could someone please remove the "Resolution-By Design" label?

[sharwell]

@cremor I am not able to reproduce this issue with the 8.0.300 SDK. After both step 3 and step 5, only IDE0300 is displayed. I believe this issue may have been resolved in a newer version than 17.10.1 (I'm on Version 17.11.0 Preview 3.0 [35012.247.main]).

[cremor]

@sharwell I can still reproduce the problem in VS 17.10.3 (SDK 8.0.302). But then I've tested 17.11.0 Preview 2.1 and it indeed seems to be fixed in that version. Thanks!

But I noticed another difference that I'd like to discuss (unrelated to the original issue):
When EnforceCodeStyleInBuild is enabled, VS 17.10.3 shows both IDE0300 and IDE0305 warnings in the build log when I build the project.
But 17.11.0 Preview 2.1 doesn't show any warnings in the build log. Even if I remove the dotnet_diagnostic.IDE0305.severity = none line from the editorconfig and/or install SDK 9.0.100-preview.5.24307.3 I still don't get any warnings in the build log.
Is this difference expected?

[sharwell]

Closed as Not Repro