-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[Analyzer] Make types declared in an executable internal #78388
Comments
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsVarious 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.
|
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 (?) |
Could the analyzer run when the output binary contains runnable entry-point? |
Should this consider the OutputKind |
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! |
You can add an |
I assume it will also be enabled by setting |
Indeed, that is correct. |
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.
The text was updated successfully, but these errors were encountered: