Sunday, October 14, 2007

TfsBuildLab v1.0 is out there !!!

Finally we are feature complete as we intended it to be from the start (download it from here) we missed out intended deadline by almost 3 weeks :( (before 22/9) but for a sparetime project it still is decent... We have now been dog fooding TfsBuildLab in production since 2007-04-24 on a several projects the largest of them consisting of 5 parallel development branches each containing aproximately 10 000 source files.

Some statistics since the start (didn't have the time to do the graphs this time):

2998 Automatic cleanups
1554 Scheduled builds
1359 Continous integration builds

And here's how it looks over time:

What's new in version 1.0?


* Automatic rescheduling when adding new scheduled trigger.
* A report for displaying statistics from the triggers and retention policies.
* Support for overriding build script parameters both for CI and queued builds.
* Support for only deleting the build drops.
* Support for configuring retention policies based on build quality.
* Performance improvements by introducing caching

Admin Client

* Added feedback when delteing multiple builds.
* Support for forcing recaching on the server.
* Support for overriding build script parameters on queued builds.
* Support for overriding build script parameters on triggers.
* Added range paramters when listing log entries to limit the result data.

Checkin Policies

* Removed the need for TfsBuildLab when using the restricted paths policy.

Build Task

* New custom build task to use overloaded parameters (LoadOverriddenProperty)

Please let us know if you are using it, if you have trouble using it or if you have any requests for features. All feedback is wecome.

Friday, October 12, 2007

Speaking at OreDev about our experiences with implementing and extending Team System

Just wanted to do some advetising :) I'm gonna speak at OreDev this year about our experiences when implementing and extending Team System. Check out the session description here.

So if you are in the neighbourhood on November the 13th come listen and maybe swap some was stories?!?!

Automated builds of Visual Basic 6 project with Team System

Way back when we started to implement TFS as our primary provider for source control and build automation we experienced a fair ammount of pain due to the fact that we had a large body of Visual Basic 6 code that we needed to build using Team Build.

Since there is still not that much information about this I decided to do a post about it.

There are not that much to it but it has one quirk that you need to understand to get it to run smoothly. You have to use the /out argument and supply a path to a logfile that will capture the input.

It's rather easy to say nah I don't need that information and run without using this argument. The problem then will start with the fact that even if you build vb6 projects using the commandline switches the IDE will prompt for input when failures occurs and block the build script indefinitly. It wont work just using the timeout property on the exec task either since this will leave the process running and locking the files and thus you will get a failed build the next time when Team Build attempts to clear the workspace.

Using the exec task

"This approach requires no external components but does not report any information back in the build report"

<VB6>$(ProgramFiles)\Microsoft Visual Studio\VB98\VB6.exe</vb6>

<target name="CompileProject"
   outputs="Compiled %(ProjectToBuild.Identity)">

<message text="CompileProject: %(ProjectToBuild.Identity)">
<makedir directories="$(VB6Output)" condition="!Exists('$(VB6Output)')">

<exec condition=" '@(ProjectToBuild)'!='' "
      /m "%(ProjectToBuild.Identity)"
      /outdir "$(VB6Output)"
      /out "$(VB6Output)VB6.log""


Using a custom build task

"This approach requires and external component which is included in my petproject TfsBuildLab. The benefits with this is that the feedback is instant in the build report. Pleas note that the script below describes what the usage would look like using the build task VB6Build"

<VB6>$(ProgramFiles)\Microsoft Visual Studio\VB98\VB6.exe</vb6>

<Target Name="CompileProject"
   Outputs="Compiled %(ProjectToBuild.Identity)" >

<Message Text="CompileProject: %(ProjectToBuild.Identity)" />
<MakeDir Directories="$(VB6Output)" Condition="!Exists('$(VB6Output)')" />

<VB6Build TeamFoundationUrl="$(TeamFoundationServerUrl)"
   Output="$(VB6Output)" />


Finally here are some links to a couple of postings that has been usefull for me when dealing with issues regarding building none Visual Studio 2005 related solutions...

Building Non-MSBuild Projects With Team Build by Aaron Hallberg
Team Build DevEnv Task by Aaron Hallberg

Building binaries targeting .NET 1.1 and .NET 1.0 in TeamBuild by Nagaraju Palla

Removing the process guidance link from your portal

Just another small post about the team project portal and the layout. If like we don't have the possibility to produce the kind of flashy process guidance that comes with the SharePoint templates provided by Team System, but still have to modify the actual process (i.e. you can't use the one provided out of the box) you might want to remove the incorrect process guidance from your portals to avoid confusion.

It is not that hard once you understand that you need to use Frontpage 2003 to edit the behaviour of your portals. So here are the steps to remove the process guidance like from an already created portal.

1, Open site in question
2, Open default.aspx for editing
3, Select the process guidance and the row below.
4, Right click and select cut
5, Save chanes made to default.aspx

That's it! But don't forget to remove the document library containing the guidance as well. Obviously it's better to actually modify the process guidance documentation or provide you own and create a new SharePoint template that's assosiated with your process template, but we are not always granted the luxury of being able to do all this during an incremental rollout of a major product like Team System.

Thursday, October 11, 2007

Creating a test server by cloning your TFS production environment

Not long ago we created a lab environment for testing out new concepts and testing upgrades on an so on. We then had the brilliant :) idea that we should perform a clone by using the disaster recovery techniques describe in the msdn article: How to: Move Your Team Foundation Server from One Hardware Configuration to Another

This worked great and we suddenly had a realistic lab environment, atleast that's what we though. Fourtunately for us we didn't have time to do anything with this new server after we created it and some time passed. During this time we created additional team projects and everything was fine.

Imagine my suprise when we started using the test server and all of the suddenly saw the new projects on this server as well. After som digging around and talking to Microsoft support we where directed to an post by Buck Hodges that points out that the problem resides in the fact that when we restore the databases on another server we end up with 2 instances of TFS running with ther same instance ID (a guid stamped in the database). Since this guid is cached on the client it can cause all kinds of nasty issues if you access both servers from the same client.

Anyway here's howto fix it:

Clear the client cache
Delete the directory %userprofile%\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache.

Clear the instance info
“%TFSInstallDir%\Tools\InstanceInfo.exe" stamp /setup /install /rollback /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <your new data tier>

Create new instance info
"% TFSInstallDir %\Tools\InstanceInfo.exe" stamp /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <your new data tier>

And here is the link to the posting Buck Hodges made about it: Creating a new server from an old one: Beware of the InstanceId

LinkMania: HowTo create a custom build step for MSBuild

There is not much to writing extensions to msbuild but I've put together afew links as a starting point.

The documentation would be a great place to start :) and it is very complete with alot of examples: How To: Write a Task

There are also a couple of really good posts on the msbuild team blog about this:
How To: Implementing Custom Tasks - Part I
How To: Implementing Custom Tasks - Part II
How To: Debug a custom MSBuild task using Visual Studio

There is also a great MSDN article on how the msbuild engine works and howto extended it here: Inside MSBuild Compile Apps Your Way With Custom Tasks For The Microsoft Build Engine

Broken navigation in team portal when deleting security or requirements document library

Lately I've been mucking about with the portal parts of Team System since we wanted to move our documents into SharePoint and gain all the benefits there.

We did however bump into a major issue that turned out to be a bug in the SharePoint templates in Team System. The bug is fixed in the upcomming release (TFS2008) in both template versions (WSS2.0 & WSS3.0).

The problem occurs when you delete certain document libraries from you portals, namely the security and requirements. This will corrupt the portal navigation (quicklaunch) and once you've ended up in a corrupted state you can not get any document libraries to appear on the quick launch.

The bug is related to some sort of hardcoding in the template concerning the security and requirements document libraries. You can test this by enabling "show on quicklaunch" in these document librareis. This will generate duplicates on the quicklaunch. And if you remove either of them the navigation breaks.

After some discussions with Microsoft support we came to the conclusion that if you delete the security or requirements document libraries (either through team explorer or through the portal), it seems that an orphaned element is left in the dbo.navnodes table of your SharePoint content database.

There is a way to remove these document libraries with out breaking the navigation. To do this you need to use FrontPage 2003 and connect to the site in question. Then open the file default.aspx and you will see the following section on the left.

Double click on either the security or requirements link and you will be presented with the "linkbar properties" dialogue. Then remove the link to the security and/or requirements document library from the quicklaunch.

When you have done this it's ok to remove the document libraries from any tool you choose.

If you like me have a trigger happy finger and don't like unused stuff and already have deleted the document libraries and are stuck with a broken portal there is a solution :).

NOTE THAT THIS IS NOT A SOLUTION SUPPORTED BY MICROSOFT!!! So you should know what you are doing when performing this recovery strategy and always make sure that you have a made a complete backup of both sharepoint databases before starting this procedure!!!

Step 1, Get the identity of the orphaned document library from the navigation nodes table.

SELECT DocId FROM dbo.navnodes
WHERE name = 'BrokenDocumentLibraryName' AND
SiteId IN (SELECT SiteId FROM dbo.Webs WHERE FullUrl = 'sites/TeamProjectName') AND
WebId IN (SELECT id FROM dbo.Webs WHERE FullUrl = 'sites/TeamProjectName')

Step 2, Verify that the document library actually is orphaned.

WHERE Id = 'DocumentLibraryIdentity'

Step 3, Remove the orphaned document library from the navigation node table.

DELETE FROM dbo.navnodes
WHERE DocID = 'DocumentLibraryIdentity'