Many people are aware of and use the MvcBuildViews property that was added to MVC in the version 1 Release Candidate. This property enabled a build target to call the aspnet_compiler.exe when the build was complete. However, when using this in conjunction with the One Click Web Publishing in Visual Studio, you may get errors about certain properties in web.config not being allowed:

In simple English, this is just stating that the precompiler found properties in Web.config that can only be allowed in the web.config file at the root of your project. What’s odd is that if you double click the error, which takes you to the offending property, it will open up what looks your web.config file. What’s not obvious is that it’s actually opening a separate copy of web.config which exists somewhere under the obj directory in your project:

In fact, if you look carefully, you’ll see that any web.config transforms that apply during publishing will be applied to this file already.

There are a number of workarounds floating around the Internet today, such as always doing a Clean before a Build or deleting the obj folder. There’s also the option of changing the $(BaseIntermediateOutputDirectory) in the project file so that it is no longer under the project root. However, each of these is an annoyance to put into place.

As part of the publishing improvements made in VS 2012, there is now built-in support for the ASP.NET precompilation and merge tools for all Web Application Projects, which includes MVC. (Side note: Web Site Projects have long supported precompilation but not merge through the Publish command). This new feature, carried in from Web Deployment Projects, now lives on the Package/Publish Web tab of the project properties:

When you use this feature, which only applies at publish time instead of build, Visual Studio is smart enough to avoid the contents of the obj directory. In fact, it’s also smart enough to only compile the files that are included in your project, which is another small issue with MvcBuildViews. With the Advanced options, you can even configure more specific behaviors, including merging your precompiled assemblies, or whether to compile your markup files (make the site not “updateable”):

The one catch with this is that the publish settings are configured on a per build configuration basis. In the screenshot above, the setting only applies to the Debug configuration. If you’re publishing with Release (which is now the default in VS2012, instead of whatever is active in VS), then make sure to configure it for that build configuration.

Also worth noting for people still on VS2010: there now is an out-of-band release for Visual Studio 2010 and Visual Web Developer 2010 which gives you the same new publish features as VS2012. This allows you to use the same new pre-compilation feature for any Web Application Projects as well. To get the VS2010 update, you can visit the Azure developer tools download page.