RazorGenerator

Generator Types

• MvcHelper: Creates a static type that is best suited for writing Mvc specific helper methods.
• MvcView: Create a WebViewPage which allows the use of precompiled MVC views.
• WebPage: Creates a WebPage type that can be used as WebPages Application Part (such as _Admin and RazorDebugger).
• WebPagesHelper: Creates a HelperPage type that is suited for precompiling and distributing WebPages helper.
• Template: Generator based on T4 preprocessed template.

Usage in an MVC app

• Install the 'RazorGenerator.Mvc' package, which registers a special view engine
• Go to an MVC Razor view's property and set the Custom Tool to RazorGenerator
• Optionally specify a value for Custom Tool Namespace to specify a namespace for the generated file. The project namespace is used by default.
• Optionally specify one of the generators in the first line of your Razor file. A generator declaration line looks like this: @* Generator: MvcHelper *@. If you don't specify this, a generator is picked based on convention (e.g. files under Views are treated as MvcViews) NOTE: The selection has other criteria such as detecting "Helper" in the filename and choosing WebPagesHelper for those.
• You'll see a generated .cs file under the .cshtml file, which will be used at runtime instead of the .cshtml file
• You can also go to the nuget Package Manager Console and run Enable-RazorGenerator to enable the Custom Tool on all the views.
• And to cause all the views to be regenerated, go to the nuget Package Manager Console and run Redo-RazorGenerator. This is useful when you update the generator package and it needs to generate different code.
• ----------------------------------------------------------------

download RazorGenerator extension

in cshtml under app_code

@* Generator: MvcHelper DisableLinePragmas: true Namespace: BSS.SubProj.Web GeneratePrettyNames : true ExcludeForCodeCoverage : true*@

--helper build action none  and custom tool:RazorGenerator

--generated cs- build action compile

Suppressing Code Analysis Rules

Apply a Suppression in “Project Suppression File (GlobalSuppression.cs) – an ideal option.

Project Suppressions

When selecting the Project Supressions File option, the SuppressMessageAttribute is placed in the projects GlobalSuppressions.cs file – Visual Studio will create one automatically. The attribute has overrides which allows you to target the exact place of the rule failure such as a class, method, field, namespace etc.

In my example, I have suppressed botth CA2210 and CA1304 rules in the GlobalSuppressions.cs. Visual Studio generates the code.

// This file is used by Code Analysis to maintain SuppressMessage
// attributes that are applied to this project.
// Project-level suppressions either have no target or are given
// a specific target and scoped to a namespace, type, member, etc.
//
// To add a suppression to this file, right-click the message in the
// Error List, point to "Suppress Message(s)", and click
// "In Project Suppression File".
// You do not need to add suppressions to this file manually.

using System.Diagnostics.CodeAnalysis;

[assembly: SuppressMessage(
"Microsoft.Design",
"CA2210:AssembliesShouldHaveValidStrongNames")]

[assembly:
SuppressMessage(
"Microsoft.Globalization", "CA1304:SpecifyCultureInfo",
MessageId = "System.ServiceModel.FaultReason.#ctor(System.String)",
Scope = "member",
Target = "Wcf.Demo.Service.ErrorHandler.#ProvideFault(System.Exception,System.ServiceModel.Channels.MessageVersion,System.ServiceModel.Channels.Message&)"
)]

Notice the the CA1304 suppression contains Scope and Target properties. This can be changed so that the suppression is scoped to a wider code base such a a namespace.

The benefits of project suppressions is cleaner code, less duplication of the SuppressMessage attribute and easier to remove if failure is fixed. It’s also easier to code review as all failure overrides are in the one place. The only disadvantage that I can see is that there is an additional code file.

Always use project suppressions.