MvcBuildViews in a CI environment

This post isn't going to break any new ground in the world of computer science, but I still wanted to say a few words about the importance of using MvcBuildViews in your continuous integration environment.

My team had just finished a quick and slightly dirty ASP.NET MVC 3 project. The three of us rapidly created a very usable internal departmental financial application with two of the members of the team being ASP.NET MVC neophytes. A lot of learning occurred during development, both about the basics of HTTP and client scripting as well as Visual Studio's ASP.NET MVC 3 tooling.

I was finishing off numerous TODO's toward the end of the project when I entered "/p:MvcBuildViews=true" in the MSBuild arguments section of the Team Build process tab. The build crashed immediately due to nonexistent namespace issues. It seems that a family of CRUD Views had been created at some point that used a Model that no longer existed. Apparently the plan had been to go back and clean up dead code, but there was never any follow-up due to other priorities. The dead Views certainly weren't hurting anything. Also, a user could only access them if they somehow typed in the correct URL, a near impossible eventuality. However, I abhor dead code and extra files in a project. It not only distorts the size and complexity of a project but also increases the size of the deployment.

Using MvcBuildViews helped me remove four Views from our final deployment package. That's a trivial amount for large, enterprise projects. However, for a small department application likes ours, that's 20% of the Views. So not only are there now dramatically fewer Views to manage, the steepness of the learning curve for new developers is reduced.