ASPX and ASCX files are compiled on the fly when they are requested on the web server. This means it’s possible that you aren’t catching compile errors associated with your views when you build your ASP.NET MVC project in Visual Studio.  Unless you’re willing to click through your entire application, rendering each view looking for errors, you application is left a little vulnerable to user issues. 

Fortunately, there’s a work around.  Open up your MVC project file in notepad or within the Visual Studio IDE by unloading the project and then editing the .csproj file (both actions are available by right-clicking on the Project Node in Solution Explorer.)  Notice the MvcBuildViews option.  It’s probably set to false.  Flip the value to true and you’ll magically start compiling your views when you build your application.

  1. <MvcBuildViews>false</MvcBuildViews>

Taking this action will slow down your builds a bit, but if you’re a hack like me, it’ll probably save your day in the long run.

Now you’re probably thinking, “Neat trick – how’s it work?”  Scroll down toward the bottom of your csproj file and you will notice the AfterBuild target triggers the AspNetCompiler action if the MvcBuildViews option is set to true. 

  1. <Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  2.   <AspNetCompiler VirtualPath="temp"
  3.                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
  4. </Target>

Great. One more thing. Let’s say you don’t want to slow down all of your builds, but you absolutely want to know if there are any compiler issues with your views before you commit your code to version control or deploy or whatever.  Here’s what you can do – change the AfterBuild condition to run if your configuration is set to Release mode. 

  1. <Target Name="AfterBuild" Condition="'$(Configuration)'=='Release'">
  2.   <!– Always pre-compile ASPX and ASCX in release mode –>
  3.   <AspNetCompiler VirtualPath="temp"
  4.                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
  5. </Target>

Now your debug mode builds will continue to be as fast as ever and you can quickly validate your views by building in release mode when you so choose.  There’s one little catch – this setup won’t consider the MvcBuildViews option whatsoever! So if you decide to go with this configuration, you might want to add a comment near the MvcBuildViews option letting other developers know they can change the MvcBuildViews option as much as they’d like but it’s not going to affect the AfterBuild action.  Or don’t include the comment and let your team members figure it out for themselves…

2 Comments to “Uncovering Compiler Errors in ASP.NET MVC Views”

  1. Good – I should certainly pronounce, impressed with your web site. I had no trouble navigating through all tabs and related information ended up being truly easy to do to access. I recently found what I hoped for before you know it in the least. Quite unusual. Is likely to appreciate it for those who add forums or something, site theme . a tones way for your customer to communicate. Nice task.

  2. You actually help it become seem so simple using your presentation but I find this topic to get actually an element that I believe We would never understand. It seems too complex and intensely broad for me personally. Im anticipating for your forthcoming post, I’ll make an effort to get used to it!

Leave a Reply

You can wrap your code with [ruby][/ruby] or [python][/python] blocks for syntax highlighting and you can use these traditional tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>