Dealing with errors is an important part of every application. Web applications aren’t an exception, in the contrary, they should be even better in graceful error handling, because of their huge amount of users.
We have three possible locations of caching errors in an ASP.NET application. The first one is the source of the error itself, by wrapping our code, which is likely to fail, in a try-catch block. This is a very good solution for the problem, since the error gets treated on the spot of its occurrence. You can decide to bubble the error forth, and catch it in the Page_Error event, or even further, in the Application_Error event, defined in global.asax. There’s a fourth opportunity, but it isn’t the best solution: define custom error pages in the customErrors section of your web.config. They are part of the apologize, not the solution for the problem, so you should restrict the use of them. Even worse, when you are on a custom error page, you have no way to get and deal with the error lead you there.
Before writing error-handling code, make sure that you do everything to prevent errors from happening. The best way to do so is to use a massive amount of validation. String.Empty and the Exists method should be very close friends of you.
But if the worse happened, you should fail elegantly, and without showing any inner workings of your application. Hold the detailed error messages to server administrators, and give user-friendly and meaningless errors to the everyday users. Also, you should log the exception (Health monitoring comes handy for this task).
As you no doubt already now it, the .NET Framework stores application configuration information in dedicated XML files, with the extension of .config. You can easily manage your application using these configuration files. When working with ASP.NET, the hierarchy is as follows:
- Machine web.config
- Root (application) web.config
- Subfolder web.config
There was a post already about them, but I failed on about every question on the exam where they were involved. So this one will be a quick repost of the old facts.
A Web Application Project is very similar to a traditional desktop project. You can control references in a specialized folder, have an AssemblyInfo.cs and a project file for controlling which files belong to the project explicitly (the Web Site model does this implicitly: what’s in the folder is in the project). Also, it provides backward-compatibility, since it was the default project type for web pages in VS 2003.
You’d like to use Web Application Projects when:
- You are migrating from VS 2003.
- Need to control the names of the output assemblies.
- Need stand-alone assemblies to reference page and user control classes.
- Need a Web Application using multiple Web Projects.
- Need to add custom steps during compilation.
And in the following scenarios, you’d use the Web Site model: