My Tech World

Deploying ASP.Net MVC Applications to Your Hosted Environment

I found myself in a very frustrating position last week as I tried to deploy my first ASP.Net MVC application to my own hosted web server.  If you’re building MVC apps for in-house use or for deployment to servers over which you have full control, you may have found the process to be quick, painless and generally quite enjoyable.  Similarly, if you’re deploying to servers running IIS7, then you may also have had a pretty good experience.

My hosting provider however, is running IIS6 and does not have configurations for MVC pre-prepared.  Customers need to raise a Tech Support ticket to request their site to be MVC-enabled on a case-by-case basis.  Not realising that I couldn’t just “build and drop”, I spent much time analysing my code and Web.Config before humbly going before the Tech Support folks and admitting I didn’t really know why my application wouldn’t run.

Here is a brief overview of the problems I encountered and what I had to do to overcome them.

Initial Deployment

I figured it was going to be a walk in the park after I read Phil Haack’s article on bin-deploying MVC applications.  However, after following his instructions to the letter and FTPing my files to my hosted server, I was greeted with an alarming and altogether unnatural-looking 404 page.  Well, that’s not right.  I pored over my Web.Config and controller classes to see what I could have done that wasn’t going to be picked up on my local machine.  Not much, as it turned out.  So in desperation, I swallowed my pride and logged a Tech Support ticket.

As it turned out, my host hadn’t installed Service Pack 1 for my account.  They did this almost immediately and I was miraculously presented with my app’s home page.  Success!

Or so I thought.  As soon as I’d closed the ticket as “resolved”, I browsed to a view page below the main home page and – horror – there it was again: that damn 404.

The Actual Problem

The full story of what my web host needed to do can be found on the ASP.Net MVC Learning page, tutorial 8.  The short of it is that I needed my hosting provider to create a wildcard script map for my account that would map all requests to the web server to the ASP.NET framework. That way, I could then use the default ASP.NET MVC route table with IIS 7.0 (in classic mode) or IIS 6.0 (which is what they were actually running).

Now the big, important “but”:

Be aware that this option causes IIS to intercept every request made against the web server. This includes requests for images, classic ASP pages, and HTML pages. Therefore, enabling a wildcard script map to ASP.NET does have performance implications.

[from the section, "Creating a Wildcard Script Map"]

What this meant was EVERY domain and subdomain I was running on my account was affected by this rule and each one that I did not want the rule applying for needed to be reconfigured individually.  This blog runs as a subdomain of my main account, so the WordPress PHP files found it all too much and my blog promptly died.

Hopefully if you find yourself in a similar situation to me, this will help you work through some of the gotchas involved in publishin MVC applications to older IIS boxes.

Tags: asp.net-mvc, deployment, hosting, web development