Vlad Hrybok's Tech Notes

Since I use ASP.NET HTTP handlers quite often, I decided to figure out what advantages IHttpAsyncHandler has compared with IHttpHandler. As I looked at many people's claim that IHttpAsyncHandler somehow magically improves performance by shifting request processing on to another thread, I realized that MSDN documentation of IHttpAsyncHandler is laking in a fundamental way: it fails to mention that simply moving request rendering onto another thread does not yield any benefit.

When you simply move your request handling logic from the original ASP.NET thread to your own thread (IHttpAsyncHandler), you gain exactly nothing because both threads come from the same pool. The benefit of IHttpAsyncHandler comes in only when your request processing thread is blocking, waiting for another thread. For example, if your request processing calls a web service, your request processing thread will wait for the IO completion happening on another thread - where request is sent to the web service. In this case there will be two threads involved: your request processing thread, and the IO thread where outgoing web service request is being executed. This is the situation where IHttpAsyncHandler can help: instead of holding on to the request processing thread while waiting for the outgoing request to complete, one can release the original request processing thread back to the pool, and finish response rendering on the IO thread after the web service request has completed. This way, instead of holding two threads for the duration of the relatively long-running process of invoking a web service, your request processing is using only one thread.

So, the bottom line is this:
- You should only concert yourself with IHttpAsyncHandler if you are running out of request processing threads.
- If you do, check your logic for whether it's waiting for an IO completion (or is using other threads for other reasons), and only if that's the case, switch to IHttpAsyncHandler.
- Otherwise simply increase the size of the ASP.NET thread pool in the web.config and stick with good ole' IHttpHandler.

CodePlex.com - a relatively new open-source collaboration platform from Microsoft that came to replace old and cranky GotDotNet - has impressed me quite a lot. Of course it closely resembles SourceForge.net, with the main difference of CodePlex being underpinned by Team Foundation Server (TFS) for source control and issue tracking functionality.

People often don't realize that TFS client that integrates into Visual Studio 2005 can be downloaded and is completely free.

I currently host a couple of projects on Codeplex:

• MS AJAX 1.0 Setup Project Prerequisite for Visual Studio 2005.
  It makes MS AJAX redistributable by including it into the Setup.exe bootstrapper prerequisite manifest. The prerequisite integrates nicely with Visual Studio 2005.
  
  
• Simple ASP.NET 2.0/C# MP3 Player.
  This application demonstrates a possibility of building a web application for home users. It includes redistributable UltiDev Cassini Web Server for ASP.NET 2.0 to not make the application dependent on the presence of IIS on users machines. The app is AJAXed to minimize music interruptions and uses Flash player to playback MP3 to avoid dependency on any particular media player. 

After releasing build 1.7 of my open-source redistributable ASP.NET-based MP3 player application, I used it for a while and I am pretty happy with its stability and functionality. The design goal for the project was to demo a concept of an easily-redistributable web application for SOHO market. With unquestionable popularity of web-based applications in the business world, removing complexity of the web hosting infrastructure to make home web applications possible as a category is poised to be the next big thing.

MS AJAX is great, but if you wanted to make an installable application with it, there was no way of including AJAX into your MSI-based setup project. I made a Visual Studio manifest that makes MS AJAX Extensions a Visual Studio Setup Project prerequisite:

To AJAX-enable your existing ASP.NET 2.0 application follow this video. It takes only a few minutes and essentially makes you create a dummy new Ajax-enabled ASP.NET application and then copy & paste relevant pieces of its web.config file into your application's web.config.

If you are planning to use Ajax Control Toolkit, then instead of creating dummy project from the "ASP.NET AJAX-Enabled Web Site" Visual Studio project template, create the dummy project using "AJAX Control Toolkit Web Site" template. Its web.config has additional entry in the <controls> section of the web.config that will be necessary for your application.