I'd like to thank those of you who provided feedback based on my last column "Will .NET Survive?" (http://www.windowsitpro.com/SQLServer/Article/ArticleID/49049/49049.html) in which I announced changes to the newsletter. Your input is valuable, and as we prepare to implement changes, it can influence our direction. I'd also like to encourage those of you who were meaning to send us suggestions to please feel free to do so this week. This week's column is going to touch on some open issues prior to the start of our new format.
For starters, one of the big stories last year was how Visual Basic (VB) 6.0 was coming to the end of its mainstream maintenance cycle. Similarly, SQL Server 7.0 reached the end of its mainstream support on December 31, 2005 (http://support.microsoft.com/default.aspx?scid=kb;en-us;912251). I mention this not because it's a problem but because there might actually be someone out there still running this product. If you are, do yourself a favor--upgrade to SQL Server 2005. There's no good reason to still be running your databases on SQL Server 7.0. If you don't use anything but the most basic features of SQL Server 7.0, SQL Server 2005 Express Edition is a free replacement. If you're using SQL Server 7.0's advanced features, you really should upgrade to SQL Server 2005. If you just want to match SQL Server 7.0's features, the upgrade to SQL Server 2005 will be relatively cheap. (Check out the "How to Buy" Web page at http://www.microsoft.com/sql/howtobuy/default.mspx for upgrade information.)
Next, I'd like to revisit Team Foundation Server (TFS). I last talked about TFS in September 2005 ("Blog Contains Important Information About TFS Beta 3," http://www.windowsitpro.com/Article/ArticleID/47579/47579.html). Since then, there have been several developments that you should be aware of.
As you probably know, TFS includes a new source control system. What you probably don't know is where to find the interface to this new system. Team Explorer is the key to its location. Team Explorer is separate from but integrated with Visual Studio 2005. If you first install Visual Studio 2005 and then install Team Explorer, the new source control system installs as an integrated part of Visual Studio 2005. However, if you install Team Explorer but not Visual Studio 2005, the client installs as a stand-alone application.
The client itself is tied to TFS, not Visual Studio 2005. This is important because TFS still hasn't been released. Shortly after the release of Visual Studio 2005, TFS received a beta 3 refresh. This refresh came with an updated Team Explorer installation. Microsoft is supporting this newest version of TFS. In fact, you can still even use the "Visual Studio 2005 / .NET Framework 2.0 Go-Live License" available on the TFS home page (http://msdn.microsoft.com/vstudio/teamsystem/team/default.aspx). Thus, you have little or no reason not to start migrating to TFS.
However, "not having" a reason "not to" migrate is different from actually "having" a reason "to" migrate. So, why migrate? For starters, there's improved task and project-management integration. But for most people, better integration is not a truly compelling reason to migrate. A far more compelling reason is to leverage Team Foundation Build. TFB is a separate set of server components that you can install as part of your TFS infrastructure. TFB leverages the power of MSBuild, which is the compilation behind Visual Studio 2005. By leveraging MSBuild, you can create an environment that automatically performs application builds. However, there's a hidden configuration step. TFB doesn't include the actual compilation engines. Instead, when you designate a build server, you need to install your compilers (aka Visual Studio 2005 compilers) on the build server so that the TFB engine can trigger the execution of the build.
However, TFB goes beyond letting you automatically create a build schedule so that you can mirror one of Microsoft's best practices. TFB also lets you trigger static code analysis and unit-test runs against your application. Thus, with a single product, you can arrange to automatically generate a daily build of your application and execute all your test procedures. This product really brings home the concepts of the daily check-in of project files and the daily build of applications. Let's face it--there are lots of process models that call for you to use a daily build as your application approaches release, but without a build lab where you can automate this process, how realistic is it to accomplish in a meaningful manner? With TFB and TFS, you can create a custom build lab with little more than a few clicks through a Team Explorer wizard. More information about TFB is available at http://msdn2.microsoft.com/en-us/library/ms181710.aspx.
