Monday, November 9, 2009

Tampa Code Camp Oslo Presentation

I gave another Oslo presentation at Tampa Code Camp over the weekend.  It was a really well-attended event and I had about 40 people at my talk.  I had some really good questions and it seemed like people are starting to understand the implications of Oslo could have in our industry.  I tweaked my ONETUG presentation based on some feedback that I got a few weeks ago and I showed some cool demo’s that I found in the Oslo Dev Center as well.  Here are the slides and code samples. 

image_2

Thursday, November 5, 2009

How to override the TFS Build number and force TFS to include files changed during the build

I had an interesting problem today.  My current client uses a custom file to store build numbers in their application and that file gets used to show the number in a couple of places in the app.  TFS defaults its build numbers to <BuildDefinitionName>_YYYYMMDD.# format, which was confusing when we were dropping the files to the build directory.  They used to have a manual process where they would physically change the revision number on this custom file before each build.  I automated that process with MSBuild/VSS a few months ago, so I had to tweak the custom task to work with VSS.  TeamBuild has a target called BuildNumberOverrideTarget, which does exactly what its name says, override the build number before all the build *stuff* happens.  So within that target, I can call my custom task that changes the file with the new version number (basically, looks at the old version number and increases it by 1).  Once you have your version number, you set the BuildNumber property, which is then used by TFS in the build process.

TeamBuild figures out the last checkin before the build started and uses that to label and get latest.  Since I am making a change to a source controlled file from within the build, my changes were not making it to the build.  For that, I had to set the changeset number that TFS should use as a reference.  I made a change to my custom task so that it returns the changeset ID for my checkin.  You then need to set the GetVersion property, which is also defined by Microsoft.TeamFoundation.Build.targets, which is the default target used by TFS.   So my target looks like this:

<Target Name = "BuildNumberOverrideTarget" >

    <AutoUpdateVersion Server="$(TeamFoundationServerUrl)">
      <Output TaskParameter="Major" PropertyName="MajorNumber" />
      <Output TaskParameter="Minor" PropertyName="MinorNumber" />
      <Output TaskParameter="Build" PropertyName="BuildNumber" />
      <Output TaskParameter="Revision" PropertyName="RevisionNumber" />
      <Output TaskParameter="ChangeSetId" PropertyName="GetVersion" />
    </AutoUpdateVersion>

    <PropertyGroup>
      <BuildNumber>$(MajorNumber).$(MinorNumber).$(BuildNumber).$(RevisionNumber)</BuildNumber>
    </PropertyGroup>
  </Target>

In order to interact with TFS source control from code, this is what you need to do:

  • Add references to Microsoft.TeamFoundation.Client, Microsoft.TeamFoundation.VersionControl.Client, Microsoft.TeamFoundation.VersionControl.Common
  • Connect to TFS
  • Create a Workspace on the build machine
  • Set a working folder for your workspace
  • Get latest to the working folder
  • call PendEdit(), which basically checks out the file. 
  • Call your function to update the file
  • Call CheckIn(), which returns the changeset ID

Here’s a code-snippet (simplified for demo purposes):

  1. //The _Server variable is provided from the build definition
  2. TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(_Server);
  3. VersionControlServer vcs = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));
  4.  
  5. Workspace workspace = vcs.CreateWorkspace("VersionWorkspace", vcs.AuthenticatedUser);
  6. string localPath = Path.Combine(Path.GetTempPath(), "TFSVersionUpdate");
  7. string localFilePath = Path.Combine(localPath, "VersionFile.cs");
  8.                                                 
  9. WorkingFolder folder = new WorkingFolder(_FilePath, localPath);
  10. workspace.CreateMapping(folder);
  11. workspace.Get();
  12.  
  13. workspace.PendEdit(localFilePath, RecursionType.None);
  14.  
  15. //Call update function
  16.  
  17. _ChangeSetId = "C" + (workspace.CheckIn(workspace.GetPendingChanges(), "Automated build number update")).ToString();
  18. workspace.Delete();
  19.  
  20. return true;

Tuesday, October 20, 2009

TFS: “Assigned To” Dropdown

Both the MSF Agile and Scrum for Team System templates define the “Assigned To” list ("System.AssignedTo") as:

<FIELD reportable="dimension" type="String" name="Assigned To" refname="System.AssignedTo">
  <VALIDUSER/>
</FIELD>

The problem with that is that the list displays every user in your domain.  I wanted to change that behavior since not every user in the domain uses TFS, plus we had some service accounts that didn’t need to get anything assigned to them, so this is how you would change it:

<FIELD reportable="dimension" type="String" name="Assigned To" refname="System.AssignedTo">
  <ALLOWEDVALUES filteritems="excludegroups">
    <LISTITEM value="[Project]\Project Administrators" />
    <LISTITEM value="[Project]\Contributors" />
  </ALLOWEDVALUES>
</FIELD>

The list will contain all users in the current project’s “Project Administrators” and “Contributors” groups, excluding any group names.  You can also make that change through the Power Tools Process Editor.

Friday, October 16, 2009

Scrum for Team System – Bug with Sprint Burndown Chart

We are using the Scrum for Team System template, and we found that the trend line was not showing up.  At first I thought that we just didn’t have enough data and the report couldn’t generate a trend, but halfway through the sprint, it seemed like there was definitely an issue.  The Trend Line was gone and the Capacity Trend (Baseline) was at zero.  Apparently there’s a bug with the report that gets shipped with the original install and you can download an upgrade here.  Just unzip the file and upload it to the Reporting Services server and tell it to replace the original.  You may need to tell the report where the datasets are located, but it worked fine for me with no changes.  Now we get all the information that we would need out of a burndown chart!

image

ONETUG Oslo Presentation

I presented an intro-level presentation on “Oslo” last night at ONETUG.  The presentation went pretty well and it seemed that people left the meeting with a pretty good understanding about the technology and what it can do and what it means for the future of software development.  Here are the slides and code samples.  I will post again over the weekend with a more detailed overview of the presentation.  Thanks to everyone that came out!

image_2

VSS to TFS Migration without SQL Express

I am finishing up a new TFS implementation at my current client. They are migrating their code from VSS. VSSConverter.exe needs a SQL Server database to perform some of the intermediate steps before getting the data over to TFS, the problem is that the converter defaults to a SQL Express database, which would be great, except that I don’t have Express installed on my laptop. MSDN tells me what to do to change this behavior, but they don’t tell me when I need to add that XML element. So after messing around with it, I found that I need to add it to the “Source” section of my Settings.xml file, so it would look like this:

  1. <Source name="VSS">
  2. <VSSDatabase name="c:\VSS"></VSSDatabase>
  3. <UserMap name="C:\VSS Migration\Usermap.xml"></UserMap>
  4. <SQL Server="."></SQL>
  5. </Source>

Sunday, April 19, 2009

Oslo Installation - Windows Installer

I was installing the Oslo CTP on my XP laptop (I've had it on my Vista PC for over a month now), but during the installation I got an error telling me that I needed a newer Windows Installer, with no additional information.  I downloaded the Installer 4.5 Redistributable, and after a reboot now my Oslo SDK Install didn't do anything.  I went into Add/Remove programs, removed "Microsoft Codename Oslo Repository" and "Microsoft Codename Oslo SDK Temporary Setup Files" and kicked off the install again and this time it all went well.  Life in CTP, i guess...