You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Analyzer] Make types declared in an executable internal #78388
Various analyzers only pay attention to internal/private types and members, as changes to public API is visible. For example, analyzers/fixers that find and remove dead code, or that recommend types without derivations be sealed. Applications, rather than libraries, however, typically aren't referenced, and public types/members are likely mistakes, such that if the mistakes are corrected and the types/members have their visibility changed to internal/private, then other analyzers can start making recommendations for them.
The proposal is to add an analyzer/fixer that runs when a compilation's OutputKind is ConsoleApplication or WindowsApplication and that flags all public types, recommending they instead be made internal.
Given concerns with some of the templates (e.g. WinForms creating the skeleton for a new form type being default) we're recommending this analyzer be opt-in. But we're probably easily convinced that it should be something else.
Category: Maintainability (?)
Visibility: None (off by default; might be nice if trimmer-style scenarios can flip it on by default)
The proposal is to add an analyzer/fixer that runs when a compilation's OutputKind is ConsoleApplication or WindowsApplication and that flags all public types, recommending they instead be made internal.
Could the analyzer run when the output binary contains runnable entry-point?
You can add an .editorconfig file to your solution and then select the severity of the rules you would like. For example: dotnet_diagnostic.CA1018.severity = warning
Activity
bartonjs commentedon Mar 7, 2023
Video
Looks good as proposed.
Given concerns with some of the templates (e.g. WinForms creating the skeleton for a new form type being default) we're recommending this analyzer be opt-in. But we're probably easily convinced that it should be something else.
Category: Maintainability (?)
Visibility: None (off by default; might be nice if trimmer-style scenarios can flip it on by default)
marek-safar commentedon Mar 8, 2023
Could the analyzer run when the output binary contains runnable entry-point?
CollinAlpert commentedon Jul 28, 2023
Should this consider the OutputKind
WindowsRuntimeApplicationas well?KennethHoff commentedon Sep 14, 2023
I see a lot of the newly added analyzers are opt-in.
How do I as a developer enable them, and more importantly, find which ones to enable? Basically, is there an easily digestible list somewhere?
I remember seeing a few good ones being added, so I worry that I'll forget about them and not benefit from them!
CollinAlpert commentedon Sep 15, 2023
You can add an
.editorconfigfile to your solution and then select the severity of the rules you would like. For example:dotnet_diagnostic.CA1018.severity = warningMore information here
cremor commentedon Sep 15, 2023
I assume it will also be enabled by setting
<AnalysisLevel>latest-all</AnalysisLevel>?mavasani commentedon Sep 26, 2023
Indeed, that is correct.