Visual Studio 2008 - Go Online

Today, our TFS server was offline for a few hours.

VS2005 is normally a pain and requires me to track what changes i have made, and then prat around for around half an hour trying to get my changes checked in.

VS2008 is a dream, just click the "Go Online" button, and off it goes and works out which files you have changed.

I think this might be one of the best new features of Visual Studio 2008

Visual Studio 2005 and Orcas co-existing, running Web Application Projects

Continuing my series of how to make Visual Studio 2005 and Visual Studio Orcas co-exist, and how Framework targeting works.

There is one further change required for web application projects:

Before conversion:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" /> 

After conversion:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" /> 

If you try this on a machine without VS.NET 2008 Beta 2 installed the project will fail to load because it cannot find the v9.0 path being referred to. The solution is to alter the converted line and replace it (using Notepad) with:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" Condition=" '$(Solutions.VSVersion)' == '8.0'" /> 

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition=" '$(Solutions.VSVersion)' == '9.0'" /> 

This way the correct version of the Web Application Projects targets will be loaded depending on the version of VS.NET you are using.

UPDATE:
This does however knacker MSBuild (arrrgh), so the best method is to modify this file in a custom task in TFS (which i guess I will create on monday)

Thanks goes to Tom Blackburn on this one

Orcas Bug? Test View

I have find the quickest way of writing code these days, is to sort of follow Test Driven Development.

I am not anal about it, I just believe it is quicker for me to write code against a unit test, and debug the unit test, rather than the application. This strategy has saved me a ton of time.

Now that I am using Orcas in my commercial environment, annoyingly enough I am getting the following error when i attempt to debug a unit test:

"Failed to queue test run 'ch3@20070806PC01 2007-09-03 13:00:53': Unable to start program 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\vstesthost.exe'."

If i just run the test, it works fine, it is only when i attempt to debug it.

UPDATE
-------------
I've discovered what was causing the problem, I have a little batch file, which i haven't update which starts the WebDevServer (Cassini), but this is launched from .NET Framework 2.0.

I never run VS directly (in my work environment), I always attach to the debugger.
For somereason when i debug the unit test, it seems to clash with the WebDevServer, and it dies a horrible death.

Visual Studio 2005, Visual Studio 2008 co-existing peacefully

If you want Visual Studio 2005, and Visual Studio 2008 to co-exist peacefully for the same projects, this might help you out.

I would recommend you minimize the impact of the conversion wizard by following this procedure.

1) Make a copy of your existing solution file (i.e. to have VS2005 and VS2008 version of the solution file, e.g. MySolution.sln and MySolutionOrcas.sln)

2) Open up the new solution, and choose not to convert any projects in the solution

This means you will be able to develop using Visual Studio 2008, and Target .NET Framework 2.0, but still be able to use Visual Studio 2005 (if required), or if other project members haven't moved across to Orcas yet.

Finally this method should also work with TFS meaning, you can develop with Orcas but your build server will know no better (I haven't tested this yet, but I'm pretty sure it will be OK as I have tested it with msbuild)

If you run into trouble you can do it manually:

For each project file in the solution change the first line from this:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

to this:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="2.0">

The important part is the ToolsVersion="2.0", this will mean that VS2008 will not attempt to convert this project, and will target framework 2.0 for you :)

Finally once you have modified all the project files, you can open the new solution file (MySolutionOrcas.sln) in Visual Studio 2008 (Orcas Beta 2)

You can now allow Orcas to convert your solution (and it will not attempt to convert any of the other projects to Visual Studio 2008)

TFS and Custom Tasks

Having created some custom tasks yesterday to extend Team Foundation Server (TFS) to set the Build Number as the Changeset.

I decided I wanted the tasks to be more flexible. I came across this article which explains how to extend your tasks to take input parameters.

Using the changeset

In one of my previous posts, I showed an article which allows you to generate an automatic build number based on Date/Time. This generates a huge number (which is a bit of pain to work with).

In this post I will show you how to modify that code to modify that task to use the changeset number as the build number (which is virtually incremental in a CI environment).

Simply reference the Team Foundation Server Assemblies required for the following using statements:

using Microsoft.Build.Utilities;
using Microsoft.Build.Framework;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.VersionControl.Client;

And now simply use this little method to get the changeset number:

private int GetLatestChangeSetId()
{           
            // Get a reference to our Team Foundation Server.              
            string tfsName = @"http://myserver:8080";           
            TeamFoundationServer tfs = new TeamFoundationServer(tfsName);
            // Get a reference to Version Control.              
            VersionControlServer versionControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));
            int latestChangesetId = versionControl.GetLatestChangesetId();
            return latestChangesetId;
}

CI (Continuous Integration) Builds

In my previous post (regarding CI Builds in TFS), I referenced a Microsoft Article on how to setup CI.

There are a couple of points i wish to make beyond this article.

1) You can keep a nightly build as well as a CI build. This is very useful, we use the CI build to verify checkin, but the Nightly build to deployment to the test team.

2) You can use the nightly build to get all sources from source and do a full build, and the CI build to give an incremental build.

I think this strategy gives the best of both worlds.

If you wish to set your CI build as an incremental build you should do the following.

Within the tfsbuild.proj file, add the following (within the ProjectExtensions Tag):

<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>

This will stop TFS from reinitalising workspaces, and regetting all sources.

Overriding the TFS Build Number

This is a useful article, and something I have just implemented.

This allows you to override the TFS build number, to generate a build number based on Ticks of the Current Time.

http://msdn2.microsoft.com/EN-US/library/aa395241(VS.80).aspx

This now allows us to have a single build number which we can use, record and track bugs against.

TFS and Continuous Integration (CI)

I've recently found this article for setting up CI in Team Foundation Server.

http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx

This includes an MSI to install on the TFS and some simple configuration.

I would recommend creating a new CI Build Type in TFS that uses incremental updates (I will discuss this in another article)

It is also worth keeping a full nightly build also.

TFS and Web Application Projects

I found this useful snippet of information on the Microsoft Website regarding TFS builds for Web Application Projects.

The May 2006 release of Web Application Projects supports building with Team Build on a Team Foundation Server (TFS). However, you will need to manually add the "Microsoft.WebApplication.targets" file to your Team Foundation Server for it to work.

1. On the computer running Team Build, navigate to the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0" directory.
2. In this directory create a "WebApplications" directory.
3. Place the "Microsoft.WebApplication.targets" file in the "WebApplications" directory. This file can be found at the same location on your developer system that has been updated with the May 2006 release of Web Application Projects.
   

After performing these steps Team Build should be able to successfully build a web-project build with the new Web Application Project type.

Scheduling a TFS Build

The simplest way to schedule a TFS Build (e.g. a Nightly Build) is to create a scheduled task in the control panel.

The syntax for the command line utility TFSBuild is:

TFSBuild start Teamfoundationserver TeamProject BuildType [/machine:buildmachine] [/builddirectory:builddirectory]

For Example:

TFSBuild Start MyBuildServer MyTeamProject MyBuildType

Cancelling a TFS Build

I know this is probably not what people want to hear but the easiest method i can find of cancelling a build is:

To kill the MSBuild Process on the Build Server.

I do wish Microsoft would give you this option from within Team Foundation Client