ASP.NET MVC Compiled Views – Use Them

Posted by: Malcolm Sheridan , on 5/2/2011, in Category ASP.NET MVC
Views: 113284
Abstract: The following article demonstrates how to use the compiled views feature in ASP.NET MVC.

Compiled views in ASP.NET MVC aren’t widely known but they’re a feature you should use whenever you build a non Debug version of your website. They check for compile time errors when you compile your website. They’re really useful for non debug versions, so you’d only want to enable this feature when you’re compiling in Release mode, or another configuration similar to that. This feature will only check your views for invalid syntax. It won’t check for invalid HTML.

Open studio 2010 and create a new ASP.NET MVC 3 Web Application project. Currently there’s no easy way to enable compiled views through Visual Studio without opening the project file. Hopefully this can be fixed in a future version. To add this feature, right click the project and choose Unload Project.



This will leave you with an empty project. Next right click the project file and choose Edit [Project].csproj. [Project] will be replaced by your project name.


This will open the project file inside Visual Studio. The project file is an XML file and what you’re looking for is the PropertyGroup section. This defines properties for a particular configuration. In this example there is only Debug and Release. If you had more configurations you’d also see them here.


Enabling compiled views is as easy as adding a new value called MvcBuildViews. This holds a Boolean value that either compiles the view or not. As a best practice I only add this to code I’m releasing into the wild, so Release configurations or similar.


That’s it! Save the file. Right click the project file and choose Reload Project. To witness the changes in action, open a view in your project. Leave the configuration as Debug and create a syntax error. I’ve removed the semi colon from the code block at the top of the page. When I compile the code there are no errors. Changing the build from Debug to Release however produces different results when the code is compiled:


Without enabling this feature, the only way to pick up this syntax error is by running the website. The biggest gain when using this feature is it saves you time. Time that could have been wasted tracking down hard to find bugs in production code.

This isn’t a well known feature of Visual Studio. Hopefully you’ll use this feature and learn to love it as much as I have.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Malcolm Sheridan is a Microsoft awarded MVP in ASP.NET, a Telerik Insider and a regular presenter at conferences and user groups throughout Australia and New Zealand. Being an ASP.NET guy, his focus is on web technologies and has been for the past 10 years. He loves working with ASP.NET MVC these days and also loves getting his hands dirty with jQuery and JavaScript. He also writes technical articles on ASP.NET for SitePoint and other various websites. Follow him on twitter @malcolmsheridan

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by voronitskiy on Monday, May 2, 2011 6:52 AM
Thanks! very useful!!!
Comment posted by Kenny on Monday, May 2, 2011 9:23 AM
Awesome was wondering if code in views would ever be checked. But why do you say this feature is only useful for building in Release mode? Wouldn't it be just as useful when working in Debug?
Comment posted by Tarn Barford on Monday, May 2, 2011 9:41 AM
Hasn't compiling views always been possible in ASP.NET? Webforms pages were compiled and you have always been able to compile views as a post build step in ASP.NET MVC.

I have previously done it and thought it offered a lot of value at development time rather than at release, but the significant extra compile time was never worth it. Perhaps the compiler and dev machines have got better since then, but these days ReSharper provides a lot of that development support when I'm developing application on ASP.NET MVC.

Also, in my experience compile errors in views have never been particular difficult to find, the whole page typically crashes and renders a stack trace! As do un-handled exceptions which will not be picked up by the compiler.

Hopefully these problems are also identified by automated browser tests with Selenium or whatever the Microsoft provides. They can also be found using HTTP level tests with mechanize and webrat which are used in Rails development for integration testing.

As far as doing it as part of a release build task, aside from the last minute compile time checks, I wouldn't think it would offered any real performance advantage over standard JIT compiled views?
Comment posted by Ali Hmer on Monday, May 2, 2011 9:53 AM
Very helpful, thank you
Comment posted by Derek Morrison on Monday, May 2, 2011 1:53 PM
Definitely helpful (and I wouldn't develop without this option), but it does slow down the compile time and development workflow considerably.
Comment posted by Malcolm Sheridan on Monday, May 2, 2011 5:52 PM

Hello! It does offer value at development time as well, but the main reason for me using this feature when I'm going into production is minimize the risk of a bad view getting through.  The extra compiling that's required has vanished thanks to the new world of super machines we have running on our desks.

Agree totally that if you do automated tests with products such as Selenium or Telerik WebUI Test Studio that they will catch these errors.  This is just the last line of defence to prevent bad code.
Comment posted by Mahesh Sabnis on Tuesday, May 3, 2011 3:59 AM
This is really an excellent article.
Thanks Malcolm for such gr8 post
Comment posted by Andreas on Thursday, May 5, 2011 2:35 AM
Did anyone try to automate this check using CI, for example teamcity.
Comment posted by Al Gonzalez on Thursday, May 5, 2011 3:45 PM
Here is a macro to toggle the MvcBuildViews property.
Comment posted by Malcolm Sheridan on Tuesday, May 10, 2011 6:05 PM

Great job on the macro!  Thanks for sharing it.
Comment posted by Felix on Saturday, May 14, 2011 1:47 PM
This feature has been in MVC since version 1. Maybe it's new for the author; but for an article that appears on ASP.NET Daily Community Spotlight written by ASP.NET MVP I would expect something more useful. For example, the author recommends using this for Release builds only. That recommendation is certainly new (at least I couldn't find anybody else recommending same) - but the author doesn't justify his recommendation. My team can't imagine development without setting MvcBuildViews to true.

Sorry for not joining comment spammers with meaningless "This post is useful - keep up gr8 work" comments.
Comment posted by Malcolm Sheridan on Sunday, May 15, 2011 7:27 PM

Hi Felix.  This article was to point out a feature that isn't well known.  I wrote this to highlight this to developers who may not know about it.

Thanks for the feedback.  
Comment posted by Jesse on Monday, May 16, 2011 1:08 PM
I just enabled compilation of my views for my staging and release environments. This created another issue for me. My App uses session inProc. Seems like an additional setting is needed to the web.config located in the views directory? Here is my error.

It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS.
Comment posted by Jesse on Monday, May 16, 2011 1:25 PM
My solution will not build with this setting <MvcBuildViews>true</MvcBuildViews>. Getting error...
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS.

I can see the benefits of using this but until I can figure out whats wrong I had to turn it off.
Comment posted by BrightChen on Wednesday, May 18, 2011 10:26 PM
Comment posted by Stephan Ryer on Wednesday, November 27, 2013 3:54 AM
Thankyou! Posted a reference at
Comment posted by Gary on Friday, December 6, 2013 9:43 AM
Has anyone resolved the error "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS."

I'm using MVC 4.5 with VS2012 Update 4

I really want to get this resolved if someone knows the workaround.