Today I rescheduled my exam (the Prometric staff was by all means flexible and helpful), so thirty minutes after my phone call in the morning I could begin it. As I knew what to expect (and the revision done in the previous two days) it wasn’t a big challenge to pass. This one also completes my MCPD in ASP.NET 3.5, which feels very good.
But there are many exams ahead for me, the next one will be ADO.NET, since I found out that I did a crappy job in the working with data sections of both ASP.NET exams. Now I dig myself deeper into the topic. There will be a brief pause in my posts, because the end of the semester is coming, and I’ll need to study some sociology too, which will be painful and irritating after all these .NET studies.
So next exam to clear out is the 70-561: ADO.NET Application Development. The Training Kit is just about to arrive (I was always optimistic). Oh, and if you’re interested in the exam itself, consider reading my fail post.
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).
There are two options of extending the page-processing behavior of ASP.NET. These are HttpHandlers and HttpModules. I’ve already written a post about the former, which you can find here. HttpHandlers are parts of the ASP.NET infrastructure which are responsible for processing a given request. Each request is served by exactly one handler. You can create your custom handlers by implementing the IHttpHandler or IHttpAsyncHandler interface.
Modules on the other hand provide a way to work with every given request. There are multiple modules working in ASP.NET for each request, for example, they are responsible for authentication, sessions, caching, and much more. Even better, they don’t override the default execution of the page life-cycle, so your forms will show up as usual. With the help of the IHttpModule interface, you can register events of the page life-cycle such as BeginRequest, or PostLogRequest. You can then add your own code into these events.
But what is the appropriate use of them?
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:
An easily navigable web site is half of the battle. I wouldn’t write about the revolutionary navigation designs and ideas here, let the web designers struggle with that. In this post, only cool and standard developer navigation will be considered. So let’s begin!
Our syllabus states the following on this objective: when to extend site map provider, treeview menu vs. site map path, programmatically manipulating site map nodes, overriding menu rendering by controls adapters, filtering site map nodes based on user roles. A nice collection.
The foundation of ASP.NET site navigation is the SiteMap. Now there are some classes with this name, so let’s lay out a terminology. The SiteMap is the XML document from where the data originates. It populates the SiteMapDataSource data source object, which looks for the web.sitemap file to get its data. It also populates the SiteMapPath control, which is a graphical representation of the sitemap, and is also known as breadcrumbs. I never understand why do they call it that way, but I have no English background.
So what’s the big deal with the epic battle between SiteMapPath and TreeView? The secret is that TreeView actually uses the SiteMapDataSource control to gain its data, so it reflects any changes made in the SiteMapDataSource. However, SiteMapPath queries the underlying web.sitemap file, without the intervention of a datasource object, so changes made in the SiteMapDataSource won’t affect it.
A little info about web.sitemap: it must be placed in the root directory, must have a root element, but you can define sub sitemaps inside elements. So the following XML is valid:
In this post (which is the 100th one in the life of the blog), we’ll review three important security-related settings that you can define in your application’s web.config file, namely: authentication, authorization and impersonation. You’ll find a very thorough article about the topic here.
First a little terminology: authentication is the process of identifying, authorization is of checking rights. A common example: when you check-in to a plane, you show your ID, passport, etc. to identify yourself. Then you show your ticket for the given plane, to show that you are authorized to be there. It’s that simple. And impersonation is the process of taking someone else’s personality, which is a bad, bad thing. So long for terminology.
There are some a few authentication types in ASP.NET. Windows authentication uses the Kerberos protocol (or NTLM) to identify itself. Let’s consider it using with and without impersonation. You’d use Windows authentication with impersonation when: