It's time to start paying attention to your source control. Many of you work for companies and build corporate web applications as part of IT shops. Hopefully, you're already quite familiar with source control and backups and code management techniques. This article is for everyone else. Or for your side projects. Classic ASP has made it easy for a lot developers to ignore source code management issues because with ASP, the website is the source control. If the site is working, the pages must be there and they're all you need (except for COM components, which most people treat differently from web pages already). With ASP.NET codebehind files and components, it will be more and more common to find websites that are running from completely compiled code, with no source code on the server. Without proper source control, this can be a disaster waiting to happen.

Let's look at the really gloomy possibility first: loss of source code. Suppose you've been developing your awesome new website completely in ASP.NET, and you don't want to have your source code available to anyone with access to your server, so you develop locally using codebehind pages, compile into assemblies, and copy the assemblies up to the server from your local machine. Everything works great, and then one day your computer's hard drive crashes. Hard. Total loss. Now you've got a really sweet website that you can't touch because the source code is lost. If you're not taking steps to protect and back up your source code for your site(s), this could happen to you.

Another issue to consider for those of you who insist on keeping your source code off of the web server is one of location. Right now, I can access my web site from any computer with FTP or FrontPage Server Extensions and edit any of my ASP pages. However, if I move everything into compiled assemblies and keep my source code on a particular local machine, I have now limited my own ability to work on the website, because I need to have those source files. As someone who typically works from several different locations each day (at the very least, home and work), I don't find this very appealing.

Of course, there are other alternatives. Most web servers hosted by hosting companies, like ORCSWeb.com (who hosts this site) or iNNERHOST.com (whom I have had success with in the past), make regular backups of the web site's files. So one option is to not use code behind files at all, keeping all of your ASP.NET pages complete with their source code, just like in the ASP world. However, this loses some of the benefits of codebehinds, such as separating presentation logic from programming code, among others. You might also keep your codebehind files on the server, which would again avoid the potential problem of losing your source code or tying you to working from one location. But again, this isn't always an option, especially if you are concerned about having your source code available to anyone with access to the server. In this case, you really need to consider using some kind of source control management software (of which there are many).

Ideally, you will want to use a source control system that provides you with:

• Security -- so that others cannot access your code without authorization.
• Reliability -- so that it is readily available when you need access to it.
• Accessibility -- so that you (or other members of your development team) can access it from multiple locations.
• Recoverability -- so that your source code can be recovered after a media failure.

At the moment, I'm still researching this issue for myself, and so I don't have any recommendations for products that meet these criteria yet. However, as I learn more I will keep this article updated. If you are using a source control application that provides the benefits listed above, please send an email to me (link below) and let me know how you like it and where people can get it.

• MSDN Using Visual Studio .NET in a Team Development Environment