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
The scenarios where the identifications might be involved:
Findings reporting - the report should nonambiguously point to the rule. Given the current VS error window design, we might be locked to the short id here (prefix + number).
Individual rules configuration - e.g. setting the diagnostics level for a particular rule
Group of rules configuration - e.g. muting all the rules in a same category/namespace/package - or whatever is decided as a good grouping dimension (if any - we might decide that only 1 by 1 is supported)
Errors and execution time reporting for Analyzers - since the unit of the execution is Analyzer (not the Rule), we need some unique identification of the Analyzers as well.
Clashes of identification within single build should be prevented. Clashes with well known Rules/Analyzers (specifically the ones we'll ship in-box, or that we might ship in foreseeble future) should be ideally prevented globaly - e.g. by reserving some specific prefixes and preventing registration of custom Analyzers/Rules with those.
Background
In the early prototype we planned to have Rules short ids (https://github.com/dotnet/msbuild/pull/9735/files#diff-ffa5a8cc14988d03c021f4d451517d358aa148a11ef06068db7298ec7ceac914R24-R33) and Analyzers FriendlyNames. Plus possibly some other identifications (Rules Titles/Categories).
The scenarios where the identifications might be involved:
There are some pre-existing lessons learned - e.g - dotnet/roslyn#40351 (comment)
Goals
Related
The text was updated successfully, but these errors were encountered: