May 2011 - Posts

• ASP.NET 404 Custom Errors & IIS

  Recently I have been spending a fair amount of time working on the NuGet Documentation site (read more about it here). One of the improvements I wanted to make to it was to add useful error pages. You know more than the YSOD (yellow screen of death). One of the major issues for me was creating a useful and informative 404 page. I wanted the page to tell the user why they got there, offer suggestions about what page they may be looking for, and allow them to search the site. So I did the development work committed the changes and had the CI machine push to the server (in the case app harbor). <system.web>     <compilation debug="true" targetFramework="4.0" />     <customErrors mode="On" defaultRedirect="~/error">         <error statusCode="404" redirect="~/404" />     </customErrors> </system.web> But I was still seeing the generic IIS sever errors! I did some searching on the internet and Twitter and found a helpful property of the response object. Response.TrySkipIisCustomErrors = true; By default IIS will see an response with an error status code (400-500) and will automatically change the content of the response to its default error page. What this property does it tell IIS not to do that if there is already content in the body of the page. Well that was easy, right? So I made the change and pushed it to the server, and navigated to a page that didn’t exist. Well the server still returned me the default 404 page, but on a 500 it would give me my custom error page. So what gives? Well here is the deal, the way routing works is that if ASP.NET cannot find a file that matches the requested URL the request is given back to IIS to handle. So in the case of a 404 ASP.NET can’t find the file so its given back to IIS who uses the default static file handler to serve the request. This would be slightly different if the route had matched but then say somewhere in our code we set the status to 404. In this case it would already be in the ASP.NET pipeline and ASP.NET would server the custom 404 page. There are two ways to solve this problem. First is the easiest which is to open up IIS Manger and go to the “Error Pages” settings under IIS and change the 404 page there to use your custom 404 page. This is fine if you can remote into the server or you’re not running in the cloud where multiple instances can be started. So how then do you make that work? Well lucky for us starting with IIS7 and later these settings can be added to your web.config file under the System.WebServer node. <system.webServer>     <httpErrors errorMode="Custom" >         <remove statusCode="404" subStatusCode="-1"/>         <error statusCode="404" path="/404" responseMode="ExecuteURL" />     </httpErrors> </system.webServer> So lets dig into what some of this code means and tell you about the tricky parts that you need to know. Before you can add a custom page you need to remove the entry for the status code as there can only be one entry per status code. The tricky bit here is knowing to set SubStatusCode to –1. This basically means all the possible sub statuses. If you like you could remove only the specific one you needed and set only the specific one. Also if you are playing around with the config you might find that there is a defaultPath attribute on the httpErrors node. This defines a “default” error page should an entry not be found in the list. The problem is that by default this is “locked” and cannot be set in an applications web.config and instead needs to be set at the machine level.  Once you add these settings to your config you should be able to see your custom error page when you navigate to a page that does not exist. As a side note this just drives home the importance of IIS Express and why you should use it for development. This would have been discovered prior to pushing changes to the live server that way. Posted May 27 2011, 12:12 PM by Matthew M. Osborn Filed under: ASP .NET

• Introducing NuGet Docs: Community Driven Documentation

  http://docs.nuget.org Introducing NuGet Docs: http://docs.nuget.org! NuGet Docs is a community driven documentation site that provides guides, walkthroughs, and information about anything and everything NuGet related. NuGet Docs is your new resource for learning and understanding how to use NuGet to the fullest. There is information about how to use NuGet to consume packages, information about how to create your own packages, and even information about how to contribute to NuGet along with much more. This is the first iteration of the site and the documentation that is contained on it. So we hope you understand it might be rough around the edges, but here is the good news its community driven so you can contribute your knowledge and understand to help make it better. More about how to do that later. Let’s talk about the reason, goal, and focus behind NuGet Docs for a minute. Historically speaking open source software lacks good documentation. NuGet Docs is the NuGet team’s effort to make documentation a first class citizen. We want our documentation to be just as awesome as our product, because no matter how awesome NuGet is if no one can understand it, it’s nothing more than “the suck.” The focus of the site is really about providing the user with the information they need. We don’t want so much flashy chrome that it blinds the user from the information they are looking for. First and foremost the number one priority of the NuGet Docs site is the content! Another key aspect of NuGet Docs is that we designed it to be easy to create, update, and maintain the documentation. So let’s talk more about how we achieved that. NuGet Docs is an ASP.NET WebPages application extended to support the use of markdown files (.markdown). What this means is that the core of the site is coded in ASP.NET WebPages while the documentation itself is written in markdown. For those of you unfamiliar with markdown it is basically a more human readable way to annotate a document so that HTML can be created from it. More information about Markdown can be found here. By using markdown we allow the authors of the documentation to have a better experience while still allowing rich visual content to be created. We also wanted it to be easy to create new content on the site. With that in mind all that is required to create a new page is add a markdown file and it will be added to the site and show up in the menus. There are some conventions that need to be followed but you can read more about that in the "Contributing to NuGet Documentation" page on NuGet Docs (I know, so meta). So what are you waiting for? Head over to the NuGet Docs site and read up about anything and everything NuGet. When you’re done why not take the time to contribute your knowledge to collective (Star Trek reference) and write some documentation yourself? For those of you that do contribute to NuGet Docs we have a preview site (http://preview.docs.nuget.org) that all changes will be pushed to and then when a new version of NuGet is released we will port the preview site to the live site. This means that you can even help write documentation for features that are not in the current released version but are in CI builds. We know you love being on the bleeding edge. Also we appreciate hearing your feedback and hearing about bugs you encountered (hey, why aren't you submitting patched for them?). You can provide those opinions and issue on the NuGet Docs CodePlex site. Posted May 11 2011, 05:18 PM by Matthew M. Osborn Filed under: NuGet