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.
@Url.Content("~/Content/Images/Logo.png")
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!
Conclusion
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.