Hosting Considerations for MVC3

by David Talbot

MVC3 is ready to go with go-live licensing right now. Learn what you need to know to get your MVC3 into production today with your existing .NET 4.0 capable host.

MVC3 is taking the web application development world by storm and new projects are spinning up everywhere. Unfortunately as with any new technology if you're not aware of the implications of today's decisions in development on tomorrows deployment to a production web server you'll find yourself in a world of hurt.

URL References

During the development process, you will probably hit F5 hundreds of times and see your MVC3 application running inside of ASP.NET's debugging web server Cassini. When you launch your application in Canssini you will see a URL like, "http://localhost:18048/Home/Index" and your MVC3 routes will be appended directly on the end of that URL.

In a real world environment, your application is likely to be deployed to a virtual directory on a production web server, resulting in your URL being pre-appended with the name of your virtual directory like "http://www.yoursite.com/YourDirectory/Home/Index". Even if you plan on having your MVC3 application take over the root of the URL, at some point in the future your application could just be a sub-directory of another application. With this in mind, it is very important to always use the tilde "~" virtual root reference consistently throughout your application.


For links to controllers and actions in your application, always use the @Url.Action function.

If you need to get the virtual root in JavaScript for some client side URL building, you can set a variable on the document object to be available to all of your scripts by mixing a little server side and client side code.

document.VirtualRoot = '@Url.Content("~/")';

Get Into IIS Early and Often

It's helpful to set up a virtual directory on your local machine's IIS server to test your application in frequently so you can find broken virtual root references early in your develop cycle instead of later, when your application is hosted in a different sub-directory.

Configuring your application in IIS early on also can help you more efficiently test and debug a large application. For example, if you're working on a web page that you have to login and navigate 5 links to get to, hosting in IIS will allow you to just refresh the browser window. If you're running your application through F5 you'll have to re-login and navigate back to your page every time.

How to Host MVC3/Razor in a .NET 4.0 Host

MVC3 is currently in release candidate 2 status and as such there aren't any hosting providers that provide out-of-the-box support for MVC3 or Razor. Even once MVC3 goes final, many hosting providers won't have it installed on the server for some time.

When you install MVC3, it is installed in the global assembly cache (GAC) of your machine and is then referenced by Visual Studio.NET 2010 through the GAC by default. Long term, this is good behavior as .NET framework pieces are shared across a server. Short term this is bad because your hosting provider is not likely to have the MVC3 DLLs in place to run your application.

In order to include the MVC3 DLLs to build inside of your application, expand out the references node and set the "Copy Local" property to true for System.Web.Mvc, System.Web.WebPages and System.Web.Helpers. Setting this property will make the build process copy these DLLs to your application's /bin folder instead of using the version in the GAC.

In order to include the MVC3 DLLs to build inside of your application, expand out the references node and set the "Copy Local" property to true for System.Web.Mvc. Setting this property will make the build process copy these System.Web.Mvc version 3 DLL to your application's /bin folder instead of using the version in the GAC.

Publish your web site which will build it and remove the source code files that are compiled into the finished site and put it into a directory intended to be xcopy deployed. You do this by choosing Build->Publish in Visual Studio.NET 2010. In the dialog that appears, choose "File System" as the publish method and pick a directory on your local disk for it to copy the files to.

Next, you will need to copy the DLLs that MVC3 would typically want to access from the global assembly cache to your published application's /bin folder.

In order to get full Razor support in an MVC3 application being deployed to a vanilla .NET 4.0 framework server, you will need to manually copy a few DLLs that you don't reference directly in your project but are instead referenced by DLLs you do reference. As such, it's easier to just copy the following five DLLs from C:Program Files (x86)Microsoft ASP.NETASP.NET Web Pagesv1.0Assemblies to your published application's /bin folder.

  • Microsoft.Web.Infrastructure.dll
  • System.Web.Helpers.dll
  • System.Web.Razor.dll
  • System.Web.WebPages.dll
  • System.Web.WebPages.Razor.dll

Once you've copied your dlls into your published ASP.NET site, you are ready to upload your published folder to your .NET 4.0 web host. It is important to note that MVC3 requires medium-trust to work correctly, which should not be a problem for most shared web hosts but as with anything that is configurable, there is a chance your hosting provider might have key permissions disabled. Always test before taking down your current production instance!


With a little planning your first MVC3/Razor deployment can go without any headaches. You can deploy it today on any .NET 4.0 equipped web server and soon as more web hosts support MVC3 out of the box it will go even easier.

This article was originally published on Thursday Mar 31st 2011
Mobile Site | Full Site