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.
End of Article
