Stylecopanalyzers: SA1649 conflicts with default Razor Pages file/class naming

[chris5287]

When creating a Razor Page it will generate a .cshtml and .cshtml.cs files. The model used inside this file is postfixed with Model, which causes SA1649 to be violated.

Eg: When creating a Razor Page called Index, the files generated will be called Index.cshtml and Index.cshtml.cs, but the class generated will be called IndexModel.

Not sure if this case should be allowed in SA1649, as I don't want to switch this rule off for the whole project and adding #pragma warning disable/restore to every Razor Page seems excessive to me?

[sharwell]

I'm trying to find an example .cshtml.cs file in a repository on GitHub, but so far all I've found is .cshtml files. Can you describe where these files are getting placed?

[sharwell]

For example, this file suggests it would suffer from the same problem, but unfortunately Est_Details.cshtml.cs does not appear to exist.

[chris5287]

Razor Pages is a new feature in ASP.NET Core (https://docs.microsoft.com/en-us/aspnet/core/mvc/razor-pages/?tabs=visual-studio)

Plenty of examples in @DamianEdwards sample repos (E.g.: https://github.com/DamianEdwards/aspnetcore-app-workshop/tree/master/src/FrontEnd/Pages)

[sharwell]

@chris5287 I'm not sure how to proceed in the long run; the page describes the naming as "by convention", yet they totally ignored the much longer-established convention where code file names match the declared type. The StyleCop Analyzers rule appears to be functioning exactly as intended. I would suggest one of the following approaches for now:

1. Marking the code-behind class as partial
2. Using @model Index instead of @model IndexModel
3. Renaming the code behind file to IndexModel.cs

[af4jm]

@sharwell

I know I'm late to the party here, but your suggestion #2 would break the convention that's been in place since the beginning of MVC where model classes end with the Model suffix to distinguish from similarly named objects (usually entities), #3 requires also renaming the .cshtml file, which is part of the URL.

The gotcha here is that in traditional MVC, the cshtml files had no code-behind & the models live in a separate folder... now with Razor Pages the model is the code-behind, which for many scenarios is much cleaner by having related pieces together, but does break this rule as the two long-standing conventions now conflict with each other.

It would be nice if rulesets could apply by subfolder instead of strictly at the project level, but I have a hunch the amount of effort required to make that happen means I'm not likely to see it anytime soon.

Meantime, as ugly as it is, I'm setting my convention to be the first line of all Razor Page code behinds/models is #pragma warning disable SA1649.

[saciervo]

Thanks @af4jm for pointing out the problems with the second and third of @sharwell's suggestions

I just want to add the following for the first suggestion: Making the code-behind partial is widely considered as a code smell because it is technically an unnecessary keyword which just clutters the code. I would prefer to not use this approach.

[zloveless]

Agreed with @saciervo on the use of partial. For now, I think our team will just apply [SuppressMessage] to every single page model class.

[daviddunson]

Between the two conventions, I believe that StyleCop should win; however, 1) considering that the MVC developers decided to not follow StyleCop in their design considerations, 2) it is not likely to change and 3) everyone is going to just suppress the warning anyway, StyleCop should ignore this warning for .cshtml.cs files, or at least alter the rule so that it accepts "IndexModel" as an acceptable class name inside "Index.cshtml.cs".

[sharwell]

@daviddunson That should be possible using .editorconfig in 16.3.

[*.cshtml.cs]
dotnet_diagnostic.SA1649.severity = none

[daviddunson]

According to this article, this will only suppress the warning in Visual Studio and the CI builds will fail.

Conventions that are set in an EditorConfig file cannot currently be enforced in a CI/CD pipeline as build errors or warnings. Any style deviations appear only in the Visual Studio editor and Error List.

[sharwell]

@daviddunson The property I described in https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/2590#issuecomment-518313609 is a new compiler feature, separate from the article you linked to and new for the 16.3 release.