Purple Kate

VS 2008 Check-in Policy fails to load with VS 2010

purple.kate — Fri, 21 May 2010 10:44:00 GMT

I created a custom check-in Policy a while ago for VS 2008. However, it's not loading under VS 2010, causing a Policy Warning - very annoying.

It seems I'm not the only one having this issue - http://connect.microsoft.com/VisualStudio/feedback/details/553740/vs-2008-tfs-checkin-policies-fail-to-load-with-vs-2010

Understanding the new style Team Build under TFS 2010

purple.kate — Wed, 19 May 2010 19:23:00 GMT

I found this series of posts about customising Team Build 2010 from Ewald Hofman:

http://www.ewaldhofman.nl/?tag=/build+2010+customization

Now I am beginning to understand how the new style Team Build works - thanks Ewald.

I have a very clear idea of what I want to achieve with my Customised Builds:

Produce output that is targeted at multiple Environments (e.g. Function Test, Live etc)
- This will mean using a Build Configuration file containing the configuration values required for each Target Environment. I already have this kind of file that I used under Team Build 2008: each Environment Section contains one or more Project Sections, and each of these contain replacement configuration settings for one or more project config files (i.e. App.config, web.config, etc).
- Each Build definition will select the Target Environment(s) and Project(s) relevant to that Build.
- For each Environment, Custom Activities will:
  - Read the settings from the Build Configuration file mentioned above,
  - Amend the relevant project configuration file with the required settings,
  - Compile the project (or Publish, is it's for a ClickOnce Deployment),
  - Replace the amended project configuration file with the latest version (so the next Environment has a 'virgin' version).

Give each Environment/Project combination a version number
- I managed to do this for ClickOnce output under Team Build 2008 and I want to extend this to other types of output - websites, web services etc.
- I would also like to use this version number for our Assemblies and Ewald Hofman has a great example for doing this here: http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx.

Do the migrated Builds work?

purple.kate — Wed, 19 May 2010 19:22:00 GMT

Well my builds have been migrated - but do they work? The short answer is NO they don't, for a variety of reasons.

Here comes the fun (or perhaps, irritating) bit, working out why none of the builds are working.

Firstly I have a Team Project that holds all of my custom Build Tasks, so this is the place to start:

I opened my Build Task solution, and upgraded it to VS2010. The code successfully compiled.
I have some unit tests, so I ran these. Well some of my tests failed.
One of my custom Build Tasks uses the TFS object model - and it turns out that TFS object model has changed enough that my existing code won't work!
This is annoying as we have a couple of internal applications that 'talk' to Team Foundation Server and now I will have to update them. This is additional expense that we were not expecting.

I have now spent a couple of days trying to get my migrated builds to work and come to the following conclusions:

Any code using the TFS object model will have to be upgraded.
Where there are only 32-bit versions of 3rd Party Assemblies, I will need to use a 32bit Build.
My custom tasks just are not working properly even after upgrading to .NET 4.0. and using the TFS 2010 object Model.
I either
1. need to make my custom tasks work or
2. I should start to use the new style builds and do my customising in the Workflow rather than MSBuild.

After a long discussion with my boss, we have decided to go with option b: Customise the workflow.

Visual Studio 2010 and other software

purple.kate — Wed, 19 May 2010 19:20:00 GMT

OK so now I have upgraded to TFS 2010 what other software do I need? Well this is what I installed:

Visual Studio 2010 Ultimate (includes Team Explorer) - hey I have an MSDN subscription.
Visual Studio 2010 SDK
I found some other stuff on http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx
- So I installed Team Foundation Server 2010 Power Tools

Note to Self: I must remember to upgrade our custom checkin policies

Migrate from TFS 2008 to 2010: Practice run

purple.kate — Wed, 19 May 2010 19:17:00 GMT

We have decided, because of our customisation of TFS 2008 Build, to have a practice run at migrating to TFS2010. So I found a spare server that was just knocking about - actually its my normal dev machine - running Server 2008 R2 and I already have SQL 2008 installed.

So the first port of call was to get hold of the latest copy of the TFS Installation Guide from here: Installation Guide for Team Foundation 2010

I used the "Checklist: In-Place or Migration Upgrade of Team Foundation Server on One or More Servers" checklist - what a mouthful!

Step One: Back up your old Team Foundation Server databases:

I nearly had a heart attack reading these instructions in the Checklist. I clicked on the "How to: Back Up a Team Foundation Server (Visual Studio Team System 2008 Team Foundation Server)" link and thought we haven't been backing up out TFS2008 database in this way. Then I realised that these are the instructions when using SQL Sever 2008.

So I used this link instead: How to: Back Up a Team Foundation Server (Visual Studio 2005 Team Foundation Server). Big sigh of relief, we are backing up the TFS databases held in SQL Server 2005 in the right way. So I go and search for a recent backup - the ops guys are on the ball, I have last night's backup copied onto my Dev machine.

Step Two: Check for supported hardware:

Well my Dev machine is all I have, so it will have to do.

Step Three: Check for required permissions and user accounts:

Yep, got those.

Step Four: Check for supported environment settings

As far as I can tell these are the same as TFS 2008, so should be OK.

Step Five: Set up IIS:

I have already done this, but verify that the settings are OK.

Step Six: Set up SQL Server and Verify:

I already have SQL Server 2008 up and running, but I didn't have the Full Text Search Feature. That's now sorted.
I have decided not to bother with Reporting in this practice run.
I have verified that my SQL Server setup is good.

Step Seven: SharePoint:

I am not going to use SharePoint in this practice run, so I skipped all the relevant sections.

Step Eight: Restore Data:

I restored all the databases into SQL Server 2008.

Step Nine: Install TFS 2010:

Wow - this is much easier than TFS 2008

Step Ten: Upgrade:

Firstly find the Configuration Tool - should be under Start>All Programs>Microsoft Team Foundation Server 2010>Team Foundation Administration Console.
I clicked on Application Tier, then Configure Installed Features.
Upgrade - don't forget, I am not using Reporting or SharePoint.
This went remarkably well.

Finally - we have a working TFS 2010. I can see history and tasks.

BTW. I nearly forgot to create an additional workspace in VS2010. I now have 2 workspaces, One that holds the latest versions of the code in TFS 2008 (I am still developing 'real' software after all ) and the new workspace that I use for the code held under my practice version of TFS 2010.

Migrating from TFS 2008 to TFS 2010: Initial thoughts

purple.kate — Wed, 19 May 2010 18:56:00 GMT

I am starting to do some serious preparation for our migration from TFS 2008 to TFS 2010.

This is our current setup:

TFS 2008, WSS 3.0 and SQL Server 2005 installed on a Windows Server 2003 machine
Single Build Agent running on the TFS Server
Developers using VS2008 Developer and VS2008 Professional.
Customised Builds, using bespoke MSBuild tasks that:
- Determines the required configuration settings and the environments that the built code will be deployed in (Target Environments) such as Function Test, UAT and Live
- Poke values into XML base config files (e.g. app.config, web.config) appropriate to each Target Environment
- Generate a customised version number (ClickOnce only)
- Publish (if ClickOnce) or copy to a folder structure in the Drop Location that reflects the Target Environment(s) and version number.

We don't run any tests or code analysis during the builds.
We use both CI and nightly builds

This is what we are aiming to end up with under TFS 2010:

CI Builds that compile, run (some) tests and possibly code analysis
Nightly Builds that run additional tests and create deployable output for Multiple Target Environments, with customised version numbers for all outputs (not just ClickOnce).
Much faster builds running on many machines.