Deploy ASP.NET MVC 2 to IIS 7.5 targeting .NET 3.5

Question

I created an ASP.NET MVC 2 application in Visual Studio 2008. I set the release build to go through the ASP.NET compiler to precompile all the views, minify Javascript and CSS, clean up the web.config, etc. Since the production deployment is going to an IIS6 server, I set up my pseudo-production deployment on my Windows 7 machine to have the application pool run in classic mode targeting the 2.0 runtime. I set up the extensionless handler in the web.config that's necessary and everything worked great.

The problem came when I upgraded the solution to Visual Studio 2010. I'm still targeting the 3.5 framework, but now I'm using MSBuild 4.0 since that's what Visual Studio 2010 uses. Everything still compiles correctly because it runs fine under Cassini, but when I deploy it to the same location (same application pool, identity, etc) it now behaves differently. I still have the extensionless handler in the web.config, but now when I navigate to the root of the application it does directory browsing, and any routes that it had previously handled now come back as 404 errors being handled by the StaticFile handler in IIS. I'm at a loss for what changed and is causing the break.

I have looked at this question, but I have already verified that all the prerequisite components are installed.

Answer 1

Did you try debugging your routes using Phil Haack route debugger on the server?

Edit:
On IIS 7.5 you dont need any special extensionless handler, this is handled automatically, you don't need to change anything. It is only necessary on IIS 6 as far as I know. Could that be the problem? what if you remove that special handler? maybe this is what is stopping it to kick in the route engine.

Edit:
I double checked, and as I thought, starting on IIS7, the default mode of a AppDomain is Integrated Mode. This means that the Asp.net stack kicks in at every request, while in classic mode, asp.net was called only when an specific extensions where called (aspx ashx axd are mapped by default to the aspnet_isapi filter).
UrlRoutingModule is kicking in at every request without requiring anything from you because it is an HttpModule and not a Handler. (it just needs to be registered in the config file of your application, no need to map it to an extension, but that's by default in an MVC app. You can open you Web.Config file and verify that you have under a node

<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>

Are you sure you deploy the MVC assemblies to the server? Check that System.Web.Mvc, System.Web.Routing and System.Web.Abstraction references have the Copy Local property set to true to be sure you use the same assemblies locally and on your production server...

If all that is correct, I don't know how to help you more... I hope this will help you, or at least put you on the right tracks.

EDIT: Oww... just read your last comment... sorry I missed that element about classic mode. Your title mentions IIS7.5 and I assumed too much things. that's why I got confused.

Honnestly now, I had to look in the book of Steven Sanderson. He has a checklist for troubleshooting IIS6 deployment. I know you're saying it's only when using MSBuild 4 that it fails, but it might still be usefull

Check that Default.aspx is set as default content page. That could be the source of 404.

Then to have extensionless urls, last time I deployed to IIS6 I used a simple wildcard map and I never had a problem... If you're still in trouble sorry that I could'nt help... not that I didnt try :) good luck

Answer 2

Couple ideas to try

• Have you run any kind of comparison between the output of the VS2008 and VS2010 projects? Just verifying that the solution upgrade didn't change anything.
• Do you have the web.config targetFramework attribute set on the compilation element?
• Are you certain you're not running into something like running a x86 application in a x64 app pool?

I'm guessing you're fine on those, but since Cassini has no problems with the application, I still lean toward web.config issues. Do you have your modules/handlers properly registered in the element? Since you're running Classic Mode, you'll need both the "old" and the "new" (reference 1, reference 2).

Answer 3

I've already posted this solution in another thread, but I'll repeat myself. Use classic pipeline mode of AppPool:

Also dot't forget to install HTTP Redirection module in Turn Windows features on or off.