About a week ago, I attended my first Philly .NET User Group meeting. I have known about them for awhile, but recently I have wanted to get more involved in the development community. The meeting took place over in Cherry Hill, NJ, and it took me about an hour to get there (I think my car is broken, I keep pulling back on the wheel, but it won't flyJ).
I got to meet several cool folks over there, including Peter Laudati, our (my) local Microsoft DE, Scott Watersmasysk of Telligent Systems (makers of Community Server), Travis Laborde, and Sam Gentile among others.
Well, I got there late, and it was standing room only. Travis was giving a lively and humorous presentation about Developer Testing techniques and tools. I would have loved to have heard the whole presentation, but I didn't want to stand the whole time. Travis made a comment that he would post slides and notes from his discussion, and I figured I would pick them up later.
Next was Scott's talk about ASP.NET tips and tricks. I managed to get a seat (on the floor) right in front, and took notes the whole time. He covered some really great stuff, from caching to trust levels, the web.config configSource attribute to AppPool memory thresholds, from the Repeater control to status codes. But the one that stuck in my mind is one I was already aware of, the AppOffline.htm file.
For those not aware, adding a file named app_offline.htm to the root of your ASP.NET application will cause all requests to be redirected to that page. You can read more over on Scott Guthrie's blog, but essentially it is a mechanism to enable site updates without providing an unstable user experience. Also, as Scott W. says, it will help prevent the locking .dll issue that is not supposed to happen.
One major problem with using appoffline.htm, though, is that not only blocks requests from the users, but also from you. If you want to verify that the deployment was successful, you can't. Of course we all should be testing and verifying in a QC/QA environment before we publish to production, but some of us just want to make sure, especially with major changes.
So this got me thinking as to other mechanisms for what I call "maintenance mode." Here are a couple ideas I came up with:
Server Farms
In a server farms/failover/load balanced hosting environment, one machine could be taken offline, updated, tested and moved back online.
Hooking the ASP.NET Lifecycle
I'm not sure if this is possible yet, stay tuned, but it seems to me that it may be possible to override the app_offline functionality, and allow access from administrative address(es). Maybe Microsoft should add this in a future version?
Custom Code
In the past I have written code to do this. I would add configuration items to specify when, and what message. I would then check on every request if "maintenance mode" was turned on. All request not originating from an administrative address would go to a maintenance page.
If you have any other ideas, feel free to let me know.
One more thing to keep in mind, from Scott G.'s blog:
One thing I pointed out in the talk that you want to keep an eye on is a feature of IE6 called "Show Friendly Http Errors". This can be configured in the Tools->Internet Options->Advanced tab within IE, and is on by default with IE6. When this is on, and a server returns a non HTTP-200 status code with less than 512 bytes of content, IE will not show the returned HTML and instead substitutes its own generic status code message (which personally I don't think is super friendly <g>).