I received this error on a page which had previously been working. That morning I had updated our site, so I was expecting some issues, but this error doesn't really tell you much. We have a maintenance screen which displays a list of records in a grid. When you click on an edit link the grid converts into an "in place" editor (a UI metaphor I thought I'd like when I initially put the form together but which, as it turns out, I really hate).

A user had reported that when they clicked on a button which saves this record that it wasn't closing and updating the list. We are using Telerik web controls for most of the site so I figured it had to do with them since I updated a number of pages, including our master page, to start using the RAD AJAX version of the controls instead of their previous version. It seems this error was being caused because I had added an instance of the RadAjaxManager control to the master page, and I already had an instance of a AjaxManager (older version) on the content page itself. Both managers were conflicting with one another, which caused this error.

All I needed to change was the "RadAjaxManager" markup code to a "RadAjaxManagerProxy" and that resolved this particular error.

ASP.NET makes it fairly simple to enable security on content hosted inside of ASP.NET (ASPX pages, ASHX, etc.) just by enabling form-based authentication. Any attempt to access those pages will automatically get redirected to a login page for authentication. However, static content (HTM or HTML pages) for example aren't passed through the ASP.NET pipeline, so anyone can access that content (unless you've set-up something like Basic Authentication) - your user's aren't required to authenticate before accessing the content.

It turns out it's pretty simple to get IIS to pass requests to ASP.NET and let it handle any permissions, logging, etc. that you may want to apply - in fact, this is how ASP.NET itself hooks into IIS. The first thing you need to do is open the IIS Manager. Right-click on the website and select properties. Click on the "Home Directory" tab, then click on the Configuration button. That will display a list of application extensions and the EXE/DLL that is responsible for those filetypes. We're going to handle any files with a .HTM extension, so click on Add. In the "Executable" field enter something like "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" - I just copied this from the ASPX extension and pasted it in. In the extension field enter ".HTM". Leave everything else as-is and click on OK. If you want to map HTML files as well, repeat this procedure and enter ".HTML" as the extension (w/o the quotes). Hit OK to all the prompts to close the various dialogs. At this point IIS will forward requests for files with either .HTM or .HTML files to ASP.NET. 

Now we need to tell ASP.NET how to handle these file types by editing the web.config file to add an HTTP handler for these types. In the system.web section, we're going to map these types to use a built-in handler called "StaticFileHandler". The web.config will look something like this:

<system.web>
   <httpHandlers>
      <add path="*.htm" verb="*" type="System.Web.StaticFileHandler" />
      <add path="*.html" verb="*" type="System.Web.StaticFileHandler" />

Save the web.config. At this point requests for .HTM and .HTML will be passed through ASP.NET and it will pass the request to an instance of the StaticFileHandler class. If you have form-based security, you will automatically be redirected to log in as well before being able to view any HTM or HTML pages (assuming you've protected all pages). The main downside to pushing this through ASP.NET is that IIS can no longer handle accessing HTM/HTML pages, which will reduce the efficiency and scalability of the site. However, with most sites this isn't really much of an issue. The other issue I've noticed is that the StaticFileHandler class automatically sets the caching of the item served up to 1 day (regardless of what you've configured in IIS), and there isn't any way of overridding this behavior short of writing your own handler.

BTW - This can be used to secure other content as well, for example, PDF files, JPG's, GIF's, etc. You would just need to add an entry in IIS like we did for HTM/HTML files and make an associated entry in the web.config. In the example above I was specifically mapping each content type on an as-needed basis. I should also mention that you can also just use a wildcard mapping in IIS (option below the one we used) which will map any file types not in the first list. In that case you don't need to modify the web.config - it should be handled by the DefaultHttpHandler class (ASP.NET 2.0 and later - this isn't the case for 1.1).

If you're interesting in writing your own handler for static files, I did some searching and found this. He includes code for his own implementation of a static file handler which includes compression and caching.

Links

This has hit me more than once already. If you create an HTTP Handler (ASHX) file, by default the context object reference (passed in to ProcessRequest) doesn't contain a reference to the Session object, so attempting to access context.Session will fail.

The fix is to add a "using System.Web.SessionState" to the using section, then inherit from the IReadOnlySessionState interface.

Ex.

using System.Web.SessionState;

public class MyAshx : IHttpHandler, IReadOnlySessionState
{

}

This will give you read only access to the session state. If you need to add to the session, inherit from IRequiresSessionState instead.

I'm not sure when this was added (if it's just in VS 2008 or if it's been there since VS 2005), but I just noticed this while I was updating the website (I just added a download section). I created a new master page for the site, then updated the original home page with one that used the new master page. The master page is now home to the header, menu, and footer with a "hole" punched in the middle for my custom content. Then I added the download page and started adding files. You might not have noticed before, but the home page has a footer which moves with the browser; it basically sticks to the bottom by using a bit of CSS. This works well on the home page, and appeared to be OK while I was working on the download page. That is. up until the number of downloads forced the page to scroll. At that point the footer actually sat on top of the downloads listed, which isn't quite the effect I was hoping for. If I changed the footer style to float, it worked well for the download page but was pretty ugly for the home page (since it's a bit sparse the footer was like 1 inch below the header).

I played around with the idea of embedding a div tag in my home page that had relative heights to force the content back to where it belonged. That didn't work out too nicely, so I briefly thought about using JavaScript to handle this instead. That seemed like overkill, so I nixed that idea. If the footer was defined in my home page content section, I could just override the CSS style for that one page. However, it's in the master page. I could define two CSS files instead, but I really didn't like the idea of having to maintain two stylesheets. That's when I noticed a new section in my master page - a content holder for the head section of the page:

That made it really simple to just add an overriding style (with the same name as the one defined in my CSS file) into the home page content. I had to move the CSS link above the ContentPlaceHolder so that it was defined before my overriding style. Then I just added a <style> section inside of the header and I was good to go. This isn't earth shaking stuff, but it was a nice addition.

Imagine this scenario: You want to create a simple user control that you can use in a few web pages. It incorporates a few JavaScript functions that change the UI slightly during a mouse click; pretty standard stuff. The script isn't particularly useful in other controls, so putting it into a common library doesn't make much sense. It could be broken out into it's own library, which can at least be cached by a browser. But that introduces another dependency in the hosting page - you have to remember to include a reference to this JS library before things will work. The easiest thing to do would be to just include the JS code inside the user control itself (I'm skipping the option of embedding it as a resource; maybe another day). Including the code in the control is pretty simple and seamless. Until you drop two instances of the same control on page. What you'll find (like I did) is that your JS code is now rendered one time for each control. That's not very cool. In fact, you run into this same issue even if you decide to move the code into it's own library - you end up with more than one reference to the library.

A relatively simple way around all this is the ClientScriptManager class that is available hanging off the Page object as ClientScript. It lets you register JS code to be rendered into the main page. You can also check for the existence of the registered code (to keep from registering it more than once, regardless of the number of controls on the page). In my case, since I'm just embedding the code right in the page, there are only two methods required for this: IsClientScriptBlockRegistered and RegisterClientScriptBlock.

The routines use the object type and the passed in name as a key; if you don't pass it into IsClientScriptBlockRegistered (or the other variants) the routines will use the Page's type. I'd suggest always passing in something besides the page type (for example, the user control type). This will keep you from running into conflicts if you happen to use the same registration name (although things will still break if you picked the same JS function names).

Here's what that might look like: