Take website offline for upgrade and display maintenance screen in ASP.NET 2.0 (and above)

Lately I’ve been doing a lot of research about Continuous Integration and Continuous Deployment practices, the latter being most relevant to this post. Basically the objective is to automate all manual labor of deploying code to production, with the obvious benefit of minimizing time and effort involved, but more importantly to reduce risk. As explained very eloquently in this book.

One important aspect of any deployment scenario is downtime. The first thing to consider about downtime is “opportunity”, that is the appropriate time for the upgrade process to take place. This is usually when we know site traffic is at it’s lowest so the impact is minimal. But even then we need to be prepared to greet users with a friendly message explaining the reasons for the downtime, especially to point out that it’s a programmed upgrade and not some catastrophic incident.

So this is where ScottGu has a great tip for us in this great post, which is really old (like 2006) but I honestly had never heard of this. Basically you place a file named “App_Offline.htm” (larger than 512 bytes, read the post) in the root folder an it will cause the application domain to shut-down, release all resources, and respond to all traffic with that static file. When you’re done just delete the file or rename it and it will magically bring the site up again. I prefer renaming the file because it’s always useful to have a quick way to bring down the site and display a maintenance screen.

This is really nice because the “.htm” file can contain any markup you wish to display to users during the downtime. One thing to notice here is that even though requests are being responded, for all intents and purposes the site is down. That means you can’t reference any css or images within the same site. So if you want to display an elaborate screen with images and styles you need reference them from another site.

Of course there are other more advanced alternatives to avoid the users from ever noticing downtime, but this works pretty well for more humble deployment strategies.

Quick Tip: Validate email address in C#.NET with Regular Expressions

Ok so this is no biggie, but sure comes useful at some point when dealing with any kind of form input validation. Actually I just found myself in the needs of such validation snippet but didn’t have any at hand, so after a while putting it together I figured what better place to store for future references than my blog!

The pattern for the regular expression I borrowed from this cheat sheet. It works very nice except for some extreme cases like one-character domain, although it does reject one-character top-level domain, but I’m sure it’d be pretty easy to adjust to specific needs.

So here’s the snippet code:

private Boolean isValidEmail(String email)
{
	Regex reg = new Regex(@"(\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,6})");
	return reg.IsMatch(email);
}

Quick Tip: Differences between Culture and UICulture

I’m currently studying to take the WebApp MCTS certification exam, this will be my first certification so I’m a little nervous and don’t know what to expect from it.  So I purchased the corresponding practice test from UCertify and been taking a couple of simulation test to discover any weak spots.

I recently discovered one of this weak spots and it’s the difference between Culture and UICulture. I’m sure a lot of people have the concept crystal clear but I’m going to allow myself a post about it so I don’t ever forget again, or have a place to look in case I DO forget xD.

Basically when you set the Culture property you specify the language to use in objects with no UI, so we’re talking about things like dates, time, time zones, numbers, etc.

On the other hand, when setting the UICulture your telling the runtime to load specific resource file to compile with the current page and to replace localized values accordingly.

A very important detail about these two properties, and a very uncommonly stated fact, is that they are tied to the system’s control panel regional configuration, even if it’s misconfigured.  The Culture property is tied to the default regional settings and the UICulture is bound to the “keyboard and other input” settings. This is actually very important because it means that the defined formats for each culture or language will be used by the .NET runtime when parsing values.

I remember having a very tedious bug a while ago, when I had recently purchased my previous laptop, which would throw an exception when parsing perfectly valid datetime strings.  After a LOT of head-banging against the keyboard I discovered that the source of the problem was the regional configuration for my OS. You see the laptop came with built-in Windows 7 in English from the manufacturer, but me being a Spanish speaking fellow am used to dates in this format ‘dd-mm-yyyy’ and would often get confuse with the English date format ‘mm-dd-yyyy’. So I messed with the configuration of the English formats in control panel to have it displayed the way I wanted it, instead of installing a different language or whatever. I assumed that configuration was used for displaying purposes only but it turns out that it was affecting the way in which the .NET framework was handling the parsing of strings to date in the English culture. So I advice you not to do that, and when receiving an exception parsing a perfectly formed date string that’s the place to look.