File Not Found for all posts and pages

Topics: ASP.NET 2.0, Business Logic Layer
Jan 27, 2008 at 9:57 PM
I am receiving a 404 File Not Found when trying to access any post or page that has been added through Admin pages. In other words, it appears that if the file DOES NOT PHYSICALLY EXIST within the site directory then ASP.NET or IIS 7.0 is not even attempting to process this request. I seem to recall this from previous versions of ASP.NET and IIS where a setting had to be applied to force ASP.NET and IIS to NOT validate that a file physically exists before trying to process the request.

Unfortunately, since I am new to IIS 7.0, and also recently started using Visual Studio 2008, I cannot seem to find the required entry or setting. I have about 9 hairs left on my head and they are all in danger of being pulled out within the next few moments.

The front page of the application pulls up fine, and so do the Admin pages, this problem only exists for pages which are being generated through the application.

Example - The first default post is titled "Welcome to BlogEngine.NET 1.3 with MSSQL provider" which I see listed and summarized on the first page of the site. Clicking the link for the title of the post should take me to this location:

http://localhost/blogengine/post/2007/09/Welcome-to-BlogEngineNET-13-with-MSSQL-provider.aspx

Everything after http://localhost/blogengine/ is dynamically generated by the application - but the request never seems to get to ASP.NET, it just dies with 404.

This same thing happens for other links too such as the Categories link and the Archive link for September all of which are located on the front page.

Jan 27, 2008 at 11:14 PM
Take a look at this article on IIS7 and URL rewriting:

Making URL rewriting on IIS 7 work like IIS 6
Jan 27, 2008 at 11:17 PM
Thanks! I'll take a look at it - while I am reading it would you care to at least tell me what module in this application actually handles all requests? When a link is rendered as this:
http://localhost/blogengine/post/2007/09/Welcome-to-BlogEngineNET-13-with-MSSQL-provider.aspx

but it is really pointing at this:
http://localhost/blogengine/post.aspx?id=97dbc6a2-c8db-4b18-b658-8a841eafa61a

something MUST be intercepting it an performing the translation, correct? What module is doing this? I have set breakpoints in all of the modules and I cannot get the request to stop.
Jan 27, 2008 at 11:27 PM
I just read the article and it seems to describe some of the issues that I am experiencing here - the problem I have is that the author clearly identifies this as a hack. Also, he takes IIS out of Integrated Mode and pushes it back to Classic mode. Now part of my frustration is with a general lack of knowledge about how and why this causes an issue and whether or not this presents issues moving forward. It is also a general frustration that is causing so many developers to abandon the .NET/IIS platform because it is wholly unstable from one version to the next. I have been doing .NET development since early 1.0 beta's and quite honestly I am shocked at how much difficulty I am having at just getting a simple application like this running.
Jan 27, 2008 at 11:55 PM
The URL rewrite is handled by the URLRewrite class. You'll find a reference to it in the web.config file under the <httpModules> section:

<add name="UrlRewrite" type="BlogEngine.Core.Web.HttpModules.UrlRewrite, BlogEngine.Core"/>

Yeah, the article is a bit over my head since I don't have IIS7. Sorry.


Jan 28, 2008 at 12:22 AM
So it's becoming increasingly obvious that this application will not run under IIS 7.0 without some significant rewriting of the request plumbing code - It turns out that NONE of the modules (including UrlRewrite) is being executed under Integrated mode, hence my inability to determine how requests are handled - it never executes the code! So, now I have configured it to use the Classic mode and as you might guess I am experiencing a host of other issues - most notably images are not showing up... ugh!

Further, I am forced now to make a decision about whether or not to try to port this code so that it will run under IIS 7 in anticipation of Windows 2008 launch, or do I go ahead and keep it as is with IIS 6 supportability.

Please don't take my frustration as a comment on the team efforts for this application - I have been wanting to check this application out for a while and have heard some good things about it. I just finally found the time to do so this weekend. I greatly appreciate the efforts for applications like this, because I learn more from looking at well written code than anything else. But what is frustrating now is the complete defragmentation of the MS development platform which makes it nearly impossible for developers, partners, or customers to keep up or know how to move forward. It has almost become worse than other platforms for which there are literally countless and poorly documented options to creating an environment. Now we are doing the same thing to this platform - I have been using MS Technologies for development for nearly 10 years, and never have I seen anything like this - it is completely disheartening, and I know of many developers who are moving to other technologies because of it. Again, please don't take this as a negative comment on your team efforts here.

As a learning point, if you haven't already begun to evaluate this application on the IIS 7.0 platform, you might want to do so... in about 3 months you are going to be getting countless questions about how to make it run... if you have already begun to do so, I'd be greatly interested in seeing what has been done so far...

Shane
Jan 28, 2008 at 2:29 AM
If you are experiencing some of these issues, please check out the resolution at this post:

http://www.codeplex.com/blogengine/Thread/View.aspx?ThreadId=21124