I've run into an interesting and odd, and perhaps inconsistent, routing behavior concerning serving files.
I've been setting up a site using a Web Site Project in VS2008 and have gotten everything in working order. Since I don't care for the idea of having a response.redirect in my default.aspx file and the resulting 'flicker' I see when I visit the site, I
created an empty default.aspx stub and created a route for it. I know I could do a server.transfer instead, but I wanted to route it. In order to make that work, of course, I had to follow the suggestion from Haacked.com and set RouteTable.Routes.RouteExistingFiles
to True. Everything works like a charm. No flicker, everything is seamless and beautiful.
However, I thought it would be smart to take this basic setup and create a template for myself so I don't have to work it all out again or reverse-engineer it from this site once it is more fully developed. So I exported the template and tested it by creating
a new project. Suddenly, it complained that there was no controller defined for localhost/mvcwebsite1/views/stylesheets/site.css. Very odd, considering it was working just fine and not complaining in my other project. Makes sense, of course. In fact, seem
like I really should have been seeing this from the other project too.
Long story short, after some fiddling, I figured out that if you set your site to use port 80 and the virtual path to "/", which I had done for my other project for simplicity, then MVC doesn't care if there isn't a controller set for your files regardless
of the RouteTable.Routes.RouteExistingFiles setting. I may be missing a subtlety of routing here... is my {controller}/{action}/{id} default route picking up on /views/stylesheets/site.css? If so, I'm not sure I understand why it changes behavior based on
changing the port and virtual path. A very odd situation indeed.
Incidentally, and this is a digression, I don't understand the attitude that only people using Visual Web Developer would ever want to use Web Site Projects. Having spent a good deal of time coding in PHP as well as ASP.NET over the years, I find the Web
Application Project very 'heavy' and I don't like the idea of VS2008 'owning' my code. The current implementation of the MVC.NET Framework definitely has a very 'PHP melded to ASP.NET' feel to it, and it's nice to 'feel the raw html in my hands', so to speak,
so it just seems natural to not want the overhead of the WAP. Just a thought, perhaps a small rant, and definitely a digression that really has no bearing on the above.
Setting RouteExistingFiles = true is the "nuclear option" for routing. It means we route all matching requests, whether or not the file exists. Setting it to false means that a request for your stylesheet won't get routed because the stylesheet exists on
disk.
By setting RouteExistingFiles = true, you workaround a known bug in routing, but open up a host of other problems.
We will have a new preview of Routing out soon that fixes this bug. I'd recommend putting the default.aspx file back for now and setting RouteExistingFiles = false for the time being.
Sure, there's a flicker, but that only applies to Cassini. It won't apply to IIS 7 because you can route the "" route to your home controller.
Phil
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
Marked as answer by Mikesdotnetting on Dec 25, 2009 08:05 PM
In the end, I agree. It works, but I had to make sure my catchall *pagenotfound route had the constraint to allow .css files to be served and I'd have to adjust that for images, pdfs, etc. On one hand, I like the idea of handling all requests, static or otherwise,
through the routing system, but on the other hand it does create the need for a lot of tweaking and fine-tuning of your routes. On an interesting note, in my post above I noted that if I set the dev server to use a static port and a root path, the files were
served regardless of the setting. Well, *today* that is not true. Normally, I'd attribute this to getting older and maybe I was mistaken, but I am pretty sure about it. Must have been a cache issue allowing me to see the css files even with the routing
for files turned on and my catchall in place. Strange, but on a good note, I've been getting some good down-and-dirty experience playing with the routing engine. I know being able to 'process' image and file requests will be useful to me at some point.
snidersh
Member
75 Points
29 Posts
RouteTable.Routes.RouteExistingFiles Behavior
May 20, 2008 05:25 PM|LINK
I've run into an interesting and odd, and perhaps inconsistent, routing behavior concerning serving files.
I've been setting up a site using a Web Site Project in VS2008 and have gotten everything in working order. Since I don't care for the idea of having a response.redirect in my default.aspx file and the resulting 'flicker' I see when I visit the site, I created an empty default.aspx stub and created a route for it. I know I could do a server.transfer instead, but I wanted to route it. In order to make that work, of course, I had to follow the suggestion from Haacked.com and set RouteTable.Routes.RouteExistingFiles to True. Everything works like a charm. No flicker, everything is seamless and beautiful.
However, I thought it would be smart to take this basic setup and create a template for myself so I don't have to work it all out again or reverse-engineer it from this site once it is more fully developed. So I exported the template and tested it by creating a new project. Suddenly, it complained that there was no controller defined for localhost/mvcwebsite1/views/stylesheets/site.css. Very odd, considering it was working just fine and not complaining in my other project. Makes sense, of course. In fact, seem like I really should have been seeing this from the other project too.
Long story short, after some fiddling, I figured out that if you set your site to use port 80 and the virtual path to "/", which I had done for my other project for simplicity, then MVC doesn't care if there isn't a controller set for your files regardless of the RouteTable.Routes.RouteExistingFiles setting. I may be missing a subtlety of routing here... is my {controller}/{action}/{id} default route picking up on /views/stylesheets/site.css? If so, I'm not sure I understand why it changes behavior based on changing the port and virtual path. A very odd situation indeed.
Incidentally, and this is a digression, I don't understand the attitude that only people using Visual Web Developer would ever want to use Web Site Projects. Having spent a good deal of time coding in PHP as well as ASP.NET over the years, I find the Web Application Project very 'heavy' and I don't like the idea of VS2008 'owning' my code. The current implementation of the MVC.NET Framework definitely has a very 'PHP melded to ASP.NET' feel to it, and it's nice to 'feel the raw html in my hands', so to speak, so it just seems natural to not want the overhead of the WAP. Just a thought, perhaps a small rant, and definitely a digression that really has no bearing on the above.
Haacked
Contributor
6901 Points
412 Posts
Re: RouteTable.Routes.RouteExistingFiles Behavior
May 21, 2008 04:42 PM|LINK
Setting RouteExistingFiles = true is the "nuclear option" for routing. It means we route all matching requests, whether or not the file exists. Setting it to false means that a request for your stylesheet won't get routed because the stylesheet exists on disk.
By setting RouteExistingFiles = true, you workaround a known bug in routing, but open up a host of other problems.
We will have a new preview of Routing out soon that fixes this bug. I'd recommend putting the default.aspx file back for now and setting RouteExistingFiles = false for the time being.
Sure, there's a flicker, but that only applies to Cassini. It won't apply to IIS 7 because you can route the "" route to your home controller.
Phil
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
snidersh
Member
75 Points
29 Posts
Re: RouteTable.Routes.RouteExistingFiles Behavior
May 21, 2008 05:02 PM|LINK