Do not report SA1649 for Razor page code-behind files - #86
Conversation
|
@bjornhellander Ready for review |
|
My memory of this issue is a bit foggy and I see that I didn't describe my thoughts very clearly in it, so I would appreciate an explanation of what you are trying to accomplish with the PR and why. For example if it's only to make sure there's no codefix messing up if the files are oddly named, or if you have found cases where the current analyzer is triggering when it shouldn't so it needs to be relaxed further? |
|
@bjornhellander No worries. Let me put in a proper description for this PR. And yes, I found it triggering on a normally-named file, not just an oddly-named one. #19's suppression required the first base type to be textually PageModel or *.PageModel, so this gets flagged: So I made SA1649 skip any file ending in .cshtml.cs |
|
The false positive when using a base class could have been handled in another way, but I agree that just skipping these files is probably for the best. |
Fixes #38
SA1649 no longer applies to any file ending in .cshtml.cs. The name of a Razor page's code-behind file is dictated by its sibling .cshtml page, not by the type inside it, so the rule has no useful signal there and its code fix would rename the file and break the page.
This replaces the heuristic added in #19, which required the first type to be a class, its name to end in Model, and its first base type to be textually PageModel or *.PageModel. That missed page models deriving from a project-local base class, which is what #38 reports.
Behavior change: NonModelClassInCshtmlCsFileTriggersDiagnosticAsync asserted that a non-page-model class in a .cshtml.cs file does report. That expectation is now inverted (the IndexHandler theory row). The case it covered — a second, unrelated type declared first in the file — is still reported by SA1402, which is the more accurate diagnosis anyway.