Precompiling ASP.NET MVC views

In a traditional ASP.NET MVC application, Razor views are compiled by the server the first time they’re requested.

Further calls will result in the same compilation results being served again. These compiled view results are then available until IIS is restarted, the application pool is recycled or the application is shut down.

When that happens and the application is restarted, the next client to request a specific view will bear the compilation cost once more. In a high volume application, the application should be kept online as more requests arrive and compilation will thus happen infrequently.

In certain scenarios, for example when the application is accessed infrequently or when view compilation simply takes to much time, precompilation is a viable solution.

It allows us to precompile the views ahead of time which precludes IIS from needing to compile them at runtime.

You can precompile the views when you are building the application in Visual Studio, on the build server when doing a build or after the application is built but before it is deployed. This last one was possible with Web Forms but I have not investigated this avenue with MVC.

Let’s look at the pros and cons of the first two methods.

Precompiling on the developer’s machine


  • Find potential view errors at compile time rather than runtime (see example below).
  • Speed up the application for developers by preventing view compilation when debugging.
  • Allows us to share views between ASP.NET MVC projects in the same solution.


  • Cannot modify views when debugging or when the application is running. It needs to be stopped, compiled and started again for changes to take effect.
  • Compiled files will appear in merge conflicts. Note that you can simply ignore the conflicts and rebuild to solution to generate the files again.
  • Generated files will be checked in to source control, polluting the repository. On the plus side this allows other developers to reuse the precompilation results.
  • Need to install a Visual Studio extension and a NuGet package.

Precompiling on the build server


  • No change in workflow for developers. They can continue modifying views at runtime, they do not need to install any tools.
  • No precompilation files in source control.


  • Will not find view errors at compile time.
  • Will not speed up the application on the developer’s machines.
  • Requires a build server and build process (for those who aren’t using one).

In my last ASP.NET MVC project, I chose the first option for many reasons but primarily because I needed to share views between projects. To do this you need to have the views compiled and then copy the compiled views in a folder in the destination project. This process would require it’s own blog post so I will leave it for a possible future post.

Error example

Here’s an example of a precompilation error I mentionned earlier:

@model TestModel



In our model we have two properties, First and Second. In the previous example an error has been introduced where the property is misspelled Seond. While this error will show up visually with a red squiggly line when you inspect the file, the application will compile just fine but throw an exception when you try to access this view.


When working on a large project with dozens of views, it’s easy to miss these errors.

Activating precompilation in Visual Studio

To activate precompilation you need to install the following NuGet package in each project which will contain precompiled views: RazorGenerator.Mvc.


You also need to install the following extension in Visual Studio: Razor Generator.


Finally you need to change the build tool for the views that need to be precompiled, often case this means all views, by setting the custom tool to RazorGenerator.


You can visit the RazorGenerator GitHub page for more information.

New Sniptaculous version

I’ve just updated Snipatculous, my Visual Studio snippets collection to version 1.01. I’m using it daily at this point and I really like how fast it can make certain scenarios.

For example, ifany will expand to :

if ($value$ != null && $value$.Any())
    // cursor ends here instead of comment
    // after value has been replaced

The main issue is the installation which consists of a file copy in Visual Studio’s snippet directory. I’ll have to investigate if I could make a Visual Studio Extension that would facilitate the installation procedure and make it seem less barbaric.

Remove Hot Network Questions from StackOverflow

While I’m at work, I try to keep distractions at a minimum so I can concentrate on my work.

Like many .Net developers I tend to use StackOverflow a lot but one thing that gets the better of my curiosity is the Hot Network Questions tab on StackOverflow. I’ve clicked on non work related questions fare more time than I’d care to admit. To remedy this, on my workplace computer, I’ve made the HNQ tab go away.


Using the Grease Monkey Firefox add-on it’s possible to create JavaScript scripts, to modify the pages you surf.

I wrote a small script to make the entire thing go away on both StackOverFlow and SoftwareEngineering :

// ==UserScript==
// @name        HNQ Hider
// @description Hides the Stackexchange HNQ

// @include /^https?:\/\/(.*\.)?stackoverflow\.com/.*$/
// @include /^https?:\/\/(.*\.)?*$/

// @version     1
// @grant       none

// ==/UserScript==



Visual Studio quick tip: Use diff for any file

It’s possible to use the Visual Studio diff tool to compare any two files.

In the Command Window type in Tools.DiffFiles followed by the two filenames. You will see there is even an auto-completion feature.


While external diff tools can be better than Visual Studio’s built-in, it has the advantage of being available everywhere you have a Visual Studio install (like on a client’s machine where you can’t install software, or a co-worker’s machine when you are giving him a helping hand).

It’s a very solid diff tool and Visual Studio users are already familiar with it from using it for merges.