On the right you find the list of articles published on this Web site in the category ASP.NET 3.5 conveniently split up in pages.
If you can't find what you're looking for, try another category from the sub menu
Details |
![]() |
|
Site Section | Articles | |
Site Section | ASP.NET 3.5 | |
Number of
items |
23 | |
Last Article Added |
1/18/2010 9:22 PM |
Below you find some of the books that I am currently reading.
ASP.NET has a handy feature that lets you easily determine an error page that gets displayed in case an error occurs on your server. Using the customErrors section in the web.config file you can assign specific pages that are displayed for specific HTTP error codes. The following example shows how 404 errors (page not found) and 500 errors (server errors) are routed to the file ~/Errors/Error404.aspx and ~/Errors/Error500.aspx respectively. All other errors are handled by the generic ~/Errors/Error.aspx page:
<customErrors mode="On" defaultRedirect="~/Errors/Error.aspx"> <error statusCode="404" redirect="~/Errors/Error404.aspx" /> <error statusCode="500" redirect="~/Errors/Error500.aspx" /> </customErrors>
Although easy to use and set up, this solution has some drawbacks that might impact how search engines see your site and how 404 errors are treated. The good news is: these problems can easily be overcome.
If you have been using the Membership features that ship with ASP.NET, I'm sure you're familiar with the CreateUserWizard control that lets a user sign up for an account on your site. One of the features of this control (in cooperation with the Membership services) is to check whether a given user name is already taken and display an appropriate message if that's the case. This is an excellent feature as it makes sure no two users can end up with the same user name.
One of the problems with this check is that it takes place at the server. This means the page goes through a full post back which takes some time. Even worse, due to security settings on the control, the two password fields are reset so the user has to enter them again in case they chose an existing user name. It would be a lot easier if you could check the user name before the page is posted back using a bit of client side script. With ASP.NET AJAX and Page Methods, this is a walk in the park.
Note: this is the last part in a series of six. If you rather read this entire series off-line, you can buy the series as a convenient PDF document that comes with the full source. Besides the convenience, buying the PDF will also make you feel good as it shows your appreciation for the articles and helps me pay the bills for my server and hosting so I can keep running imar.spaanjaars.com and continue to provide you with great content. For more details, check out this post that shows you how you can buy the entire series right now.
This is part 6 of a six-part series of articles on N-Layer design. This article series builds on top of my three part series on N-Layer design that I released in early 2007. If you haven’t already done so, be sure to check out these articles first, as a lot of code and concepts used in this new series is explained in detail in the older series.
In this last article in the series, I'll deal with security in your N-Layered web application.