Generic Handlers ASHX Files
Just as ASPX files can be compiled on the fly ("just in time"), so can handlers . Generic handlers have an extension of ASHX. They're equivalent to custom handlers written in C# or Visual Basic in that they contain classes that fully implement IHttpHandler. They're convenient in the same way ASPX files are convenient . You simply surf to them and they're compiled automatically
The following example illustrates the CustomFormHandler implemented as a "generic handler "
Writing a generic handler
1. Add a "generic" handler to the Web site. In Solution Explorer, right-click the
CustomHandler Web site node and click Add New Item. Select Generic Handler from the templates . Name the handler CustomFormHandler.ashx.
2. Visual Studio generates a handler that includes a stubbed-out ProcessRequest method and a completed IsReusable property. Open the handler's code-beside file (named CustomFormHandler. ashx. cs) and write a function to emit the form-handling code (you can borrow it from the last exercise) . Call the method from inside ProcessRequest Replace the stubbed-out method and property with real implementations .
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace CustomHandlers {
public class CustomFormHandler : IHttpHandler {
public void ProcessRequest(HttpContext context) {
ManageForm(context);
public void ManageForm(HttpContext context) {
context.Response.Write("<html><body><form>"); context.Response.Write(
"<h2>Hello there. What's cool about .NET?</h2>"); context.Response.Write("<select name='Feature'>"); context.Response.Write("<option> Strong typing</option>"); context.Response.Write("<option> Managed code</option>"); context.Response.Write("<option> Language agnosticism</option>"); context.Response.Write("<option> Better security model</option>"); context.Response.Write(
"<option> Threading and async delegates</option>"); context.Response.Write("<option> XCOPY deployment</option>"); context.Response.Write(
"<option> Reasonable HTTP handling framework</option>"); context.Response.Write("</select>"); context.Response.Write("</br>"); context.Response.Write(
"<input type=submit name='Lookup' value='Lookup'></input>"); context.Response.Write("</br>");
if (context.Request.Params["Feature"] != null) {
context.Response.Write("Hi, you picked: "); context.Response.Write(context.Request.Params["Feature"]); context.Response.Write(" as your favorite feature.</br>");
context.Response.Write("</form></body></html>");
public bool IsReusable {
3. Browse to the CustomFormHandler.ashx file . It should work in just the same way as the handler implemented in the CustomFormHandler class that you wrote in the first example
The advantage of using the generic handler is twofold. First, it's usually much more convenient to generate a simple handler than it is to create a whole new assembly to handle the request . Second, you don't need to configure either web . config or IIS (when it comes time to deploy). That is, ASP.NET and IIS already understand what to do when encountering resource requests with the extension of . ashx. Installing ASP.NET places those when mapping to IIS .
However, ASHX files have the same limitations as ASPX and ASCX files in terms of their place in an ASP.NET project. Simple generic handlers go with the project . That is, for the handler to work, it must accompany the whole project . Alternatively, custom handlers deployed as separate assemblies you can deploy and share throughout the enterprise as global assemblies (that is, strongly named assemblies placed in the global assembly cache).
Average user rating: 3 stars out of 2 votes
Responses
-
Ashith1 year ago
- Reply