Routing goes nuts on asp .net mvc 2 application that is the same app set up 2x on the same server.

Question

This is going to sound quite bizarre. I have one ASP .NET MVC 2 application. Works great. Routing is not very complicated. I am running this on windows 2003 IIS 6, so I have to use the {controller}.aspx routing configuration.

Anyhow, I've set the same MVC 2 application up twice under different virtual directories on IIS. This is literally a copy/paste of the existing app files to the new directory. The virtual directory / app name is of course different for each.

Routing works perfect in the original application. In the second, I can't seem to get the login page to post to the login post action, let alone make it beyond that.

The most complicated url in my application is something akin to:

http://server:90/appName/controller.aspx/AnAction?StartPeriod=2008

My global.asax.cs looks like:

        routes.IgnoreRoute("{resource}.html/{*pathInfo}");
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            "Default",
            "{controller}.aspx/{action}/{id}",
            new { controller = "Account", action = "LogOn", id = UrlParameter.Optional }
          );

        routes.MapRoute(
          "Root",
          "",
          new { controller = "Account", action = "LogOn", id = "" }
        );

The application only has 2 controllers: Account & Mpa. Again, the exact same compiled code exists in both places on the same IIS server under different app names/virtual directories. Can anyone think of a reason I would get different behavior in the copied one (doesn't work/can't find views/throws 404's for just about everything beyond displaying the LogOn page of Account controller)?

EDIT 1

Another thing worth mentioning is that I'm using ValidateAntiForgeryToken attributes on all post methods in the Mpa.aspx controller. This is the controller that should be redirected to after the post to Account.aspx (which doesn't seem to really happen). I thought the issue was that the salt value used for the ValidateAntiForgeryToken was the same for both applications since I copied & pasted. I've since changed the value for the original application, but I'm still getting the same results.

FYI: Here are the details returned from firebug. 

    **GET Account.aspx**
    http://server:90/MpaDemo/Account.aspx 200 OK 2.9 KB 15ms

    ParamsHeadersPostPutResponseCacheHTML
    Response Headersview source
    Date    Thu, 26 Aug 2010 20:42:57 GMT
    Server  Microsoft-IIS/6.0
    X-Powered-By    ASP.NET
    X-AspNet-Version    2.0.50727
    X-AspNetMvc-Version 2.0
    Set-Cookie  ASP.NET_SessionId=z1q43ezg2hvtx255i5y5df21; path=/; HttpOnly
    Cache-Control   private
    Content-Type    text/html; charset=utf-8
    Content-Length  2921
    Request Headersview source
    Host    server:90
    User-Agent  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
    Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language en-us,en;q=0.5
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  115
    Connection  keep-alive
    Authorization   NTLM TlRMTVNTUAADAAAAGAAYAHoAAAAYABgAkgAAAAoACgBIAAAADgAOAFIAAAAaABoAYAAAAAAAAACqAAAABYKIogUBKAoAAAAPdABtAGsAbgBiAGIAMAAwADUAagB4AGIATQBTAEoAQQBLAE0ATwBMADIANAAxADAAOADIJ4z3L+WAUAAAAAAAAAAAAAAAAAAAAABhigoN+1bIPZirxXzNQHWNIu/rx4Senq8=


    **Account.aspx POST**

    Date    Thu, 26 Aug 2010 20:44:26 GMT
    Server  Microsoft-IIS/6.0
    X-Powered-By    ASP.NET
    X-AspNet-Version    2.0.50727
    X-AspNetMvc-Version 2.0
    Location    /MpaDemo/Mpa.aspx/CustomErrorView?aspxerrorpath=/MpaDemo/Account.aspx
    Cache-Control   private
    Content-Type    text/html; charset=utf-8
    Content-Length  200
    Request Headersview source
    Host    SERVER:90
    User-Agent  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
    Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language en-us,en;q=0.5
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  115
    Connection  keep-alive
    Referer http://SERVER:90/MpaDemo/Account.aspx
    Cookie  ASP.NET_SessionId=z1q43ezg2hvtx255i5y5df21

    **GET CustomErrorView**

    Response Headersview source
    Date    Thu, 26 Aug 2010 20:44:26 GMT
    Server  Microsoft-IIS/6.0
    X-Powered-By    ASP.NET
    X-AspNet-Version    2.0.50727
    Cache-Control   private
    Content-Type    text/html; charset=utf-8
    Content-Length  1534
    Request Headersview source
    Host    server:90
    User-Agent  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
    Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language en-us,en;q=0.5
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  115
    Connection  keep-alive
    Referer http://server:90/MpaDemo/Account.aspx
    Cookie  ASP.NET_SessionId=z1q43ezg2hvtx255i5y5df21

Answer 1

Maybe switch from IIS 6 to IIS Developer Express which should run on 2003 and support all the new MVC features.

Quote from ScottGu's site:

•It works on Windows XP and higher operating systems – giving you a full IIS 7.x developer feature-set on all OS platforms

http://weblogs.asp.net/scottgu/archive/2010/06/28/introducing-iis-express.aspx

http://blogs.iis.net/vaidyg/archive/2010/07/06/introducing-iis-developer-express.aspx

Download

Answer 2

Okay, this is annoying. I forgot to check permissions on the folders I copied. Apparently, attempting to write to the log & not being able to threw an error, which my try/catch block caught, but then in the catch, I try logging the error, which threw another one, which my general catch all page should have caught, but didn't because the web.config had it under another controller.

sigh

Long story short, I removed the controller requirement for the shared error page like so:

Was: defaultRedirect="~/Mpa/CustomErrorView" Is now: defaultRedirect="~/CustomErrorView"

The view for the error page is in the Shared directory of the Views folder.

Lastly, I added the correct permissions to my logging folder.

Now it all works.

Wow. This took me 6 hours to figure out. I feel really, really lame.