I've Seen the Future and It's Hard Coded
By Jonathan Goodyear
One of the first things you learn when developing real-world applications is that hard code can get you into trouble fast. It's funny how constants don't turn out to be that constant, so it's a good idea to use them instead of hard-coded literals, lest you be sent on a long quest of search and replace. What I don't get is why Microsoft is breaking this fundamental rule of programming in ASP.NET v2.0.
To explain, if you've installed the Community Technology Preview of Visual Studio 2005 and played around with ASP.NET v2.0 for a while, you've probably noticed that Web applications now have some pre-set folders with hard-coded names that support specific functionality. For instance, the \Data folder is used for data-related files, such as Microsoft Access databases. Browser access to this folder will be restricted by default, so that visitors to your (hopefully small) Web application can't download your database. There's another folder named \Code that will contain any business logic code that you implement for your Web application (that you aren't inclined to separate into its own project). The \Themes folder will contain theme sub-directories and skin files to support the powerful new theme and skin functionality.
When I first saw these hard-coded folder names while in Redmond last August, bells went off in my head. What would happen if I wanted to upgrade an existing ASP.NET v1.1 Web site to v2.0, and I already had a \Data, \Code, or \Themes folder? I was told that I would have to change my site to accommodate the new "reserved" folder names. I didn't find that answer very savory, so I suggested two alternatives. Ideally, Microsoft would make those reserved folder names configurable in web.config (after all, everything else in ASP.NET is). If that was too much work, I would settle for more ambiguous reserved folder names to avoid naming collisions, e.g. \aspnetData, \aspnetCode, and \aspnetThemes.
Last month at the MVP Summit, I found that neither of my suggestions were currently part of the planned feature set for ASP.NET v2.0. I had a Rodney Dangerfield moment. So, in essence, the 100% backward compatibility goal only applies to your Web applications if you possess the ability to predict Microsoft's future hard-coding transgressions - or if you're just plain lucky.
Microsoft got away with the hard-coded \bin folder when they released ASP.NET v1.0, but that's only because the \bin folder has been synonymous with the location of executable code in Web applications on all platforms since Ye Olden Times. There was almost no chance of a naming conflict. This time around, things aren't going to go that smoothly if Microsoft insists on reserved folders with such generic names.
If I seem a bit cynical in my past couple of columns, then good; I'm doing my job. There are enough ASP.NET v2.0 cheerleaders out there. The reality is that v2.0 is going to be a truly awesome product, but right now it has some gaping "what the heck were you thinking?" flaws in it that there is still time to fix (given its ever expanding deadline into 2005). Your part, as always, is to write to Microsoft and make some noise, especially if your Web applications will be affected by the planned reserved folder names. For now, the best we can do is avoid these folder names in our new Web applications and hope that our message of sanity penetrates the Microsoft Reality Distortion Field in time.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.