RSS 2.0 Feed
RSS 2.0

Atom 1.0 Feed
Atom 1.0

  Set Browser Specific ASP.NET Server Control Properties and Taking an ASP.NET Site Offline 

Isn't it great when you work with a tool day after day and you thought you knew everything there was to know about it? Then find out something that has been there for a long time that you somehow missed? Here's two things that have been in ASP.NET since version 2.0 that I somehow missed until just recently. if there are only 2? Hehe. I am sure there are many more, but I was actually surprised when I came across these items. They're simple enough that I could not believe that I missed them before. I'm sure that I'm not the only one who missed these items. The fact that I hadn't heard about them indicates that they've not been blogged about heavily or that obvious in the docs (if at all?).

Setting Server Control Properties Based on Target Browser
This one was surprising. I came across this one on John Katsiotis' Web Dev & Stuff. The fact that I've written code so many times to accomplish this, when it's apparently been built in since version 2.0 just kills me. The properties of server controls will let you specify a browser filter to apply the property value for. That is, you can set a different value for a property for IE than for Firefox - and for anything else. I didn't try all properties, but I did try many that would matter, such as Text and OnClientClick etc, and they do work. Take a look at the following markup:

<asp:Label runat="server" ID="labelText" 
ie:Text="This is IE text"
mozilla:Text="This is Firefox text"
Text="This is general text"

<br />

<asp:Button runat="server" ID="buttonText"
ie:Text="IE Button"
ie:OnClientClick="javascript:alert('Hello IE!');"
mozilla:Text="FF Button"
mozilla:OnClientClick="javascript:alert('Hello Firefox!');"
Text="General Button"
OnClientClick="javascript:alert('Hello everyone else!');"

Notice the "ie:" and "mozilla:" prefixes on the Text and OnClientClick properties. The results? Take a look. The following was the result in Firefox:

In Internet Explorer:

In Opera (or anything other than IE or Firefox since I've defined properties for those)

Wow. Pretty cool. Now, I am not saying that this will apply in all cases. It doesn't seem to differentiate between IE7 and IE6, so there are some big limitations. However, this is quite a cool trick and one that will without question come in handy.

Update: I posted a follow up that shows a lot more of the capabilities of using these device filters to target specific browsers in ASP.NET.

Taking an ASP.NET Site Offline with a Message
This was another one that I was literally beside myself that I didn't know this one before. A fellow business partner of mine named James Sutton mentioned this one to me. This one's been around since ASP.NET 2.0 as well. If you have an ASP.NET web application site, and you place a text file named "app_offline.htm" in the root of the site, all requests to that website will redirect to that app_offline.htm file. Basically, if you need to take an entire ASP.NET site offline, you can place some nice message in that file. Then, any new requests to a URL, any URL, in that website will redirect to that file allowing you to do maintenance to the site, upgrades, or whatever. It is not really a redirect though. ASP.NET essentially shuts down the site, unloads it from the server, and stops processing any requests to that site. That is, until you delete the app_offline.htm file - then things will continue as normal and your ASP.NET site will load up and start serving requests again. 

A super-cool side effect of this is that any files that are locked by the site, such as a database or other resources, are freed since the application domain has been unloaded from the server. This allows you to remove the locks from those files and replace them, without the need to do a full IISRESET, taking down other sites on the server. One thing to keep in mind with this file however, make sure you out enough content in it so it is larger than 512 bytes or IE will consider it a 404 and will display the 404 instead of the contents of your app_offline.htm file.

I love coming across new tricks like this, but it does make me wonder, why didn't I know about these before?


Leave a comment below.


  1. Rob Bihun 8/14/2008 5:01 AM
    Very good info, and very useful.

    I know you can also create custom device filters and use them in many controls. But can you set browser specific properties in the codebehind?
  2. dzone 8/14/2008 8:15 AM
    Set Browser Specific ASP.NET Server Control Properties and Taking an ASP.NET Site Offline
  3. 8/14/2008 8:15 AM
    You've been kicked (a good thing) - Trackback from
  4. Alvin Ashcraft's Morning Dew 8/14/2008 10:06 AM
    Pingback from Dew Drop - Dew Drop - August 14, 2008 | Alvin Ashcraft's Morning Dew
  5. Ryan Farley 8/14/2008 10:29 AM
    Hi Rob,

    For setting browser specific properties in the code-behind, I'd just stick with Request.Browser to get the browser and then set properties accordingly.

    For example:

    switch (Request.Browser.Browser.ToLower())
    case "ie":
    if (Request.Browser.MajorVersion == 7)
    labelText.Text = "Hello IE7!";
    labelText.Text = "Hello IE (time to upgrade!)";
    case "firefox":
    labelText.Text = "Hello Firefox";
    labelText.Text = "Hello other browser";

  6. Ryan Farley 8/14/2008 10:38 AM
    BTW Rob, other than that I believe this device filtering on properties can only be done declaratively (and there's no designer support for them either).

  7. Ryan Farley 8/14/2008 12:17 PM
    More on Device Filtering with ASP.NET Server Control Properties
  8. Duncan Godwin 8/14/2008 1:48 PM
    The main problem with App_Offline is it returns a status code of 404. If your site is offline for a while using this you effectively tell search engines to drop all pages they find from their index during this time.

    We ended up writing an alternate offline web site as a fix to this which returns a 503 (service unavailable) and specifies the retry-after header to tell searche engines when they can come back.

  9. Ryan Farley 8/14/2008 2:20 PM
    Hi Duncan,

    That is correct, it will return a 404 for the original page requested, and then revert traffic to the app_offline.htm. I really don't know why a 404 was chosen for this instead of something like a 503 - which would seem like a better choice. However, IMO this should only be used for as short of a time as possible anyway (and just hope you don't get indexed while it's there!)

    I like the idea of implementing this as a handler or something else as well to specify the retry-after in the header.


  10. Gravatar
    Pingback from Weekly Link Post 55 &laquo; Rhonda Tipton&#8217;s WebLog
  11. Gravatar
    Pingback from Blue Onion Software - Friday Links #12
  12. Brian Klippel 9/15/2008 10:27 AM
    The 404 status of app_offline.htm severely limits it's usefulness in a web farm, as it can force the HLB to completely down the site based on health check failures. The status code should be user defined, but i'm afraid this feature was barely an afterthought for the dev team.
  13. Jesús García Crespo 2/10/2009 3:49 AM
    No doubt, 404 status code wasn't the correct idea. Duncan Godwin, it would be nice you post some information about the way you implement it to returns 503 code, :-).
Comments have been closed on this topic.



Also see my CRM Developer blog