After installing Team Foundation Server and Team Foundation Build, I came across a problem where I would successfully execute a Build on the project, however the build would not appear in the Build Report.

I opened up the Builds database on the TFS Server to see whether not the builds had been recognized. I found that the builds were being stored but that they were not being pulled over into the reports.

This issue is a result of the fact that the reports in TFS are pulled from the data warehouse and the not the Builds Database. In order to decrease the latency between your builds showing up in your Build reports (along with any other TFS changes not showing up in your reports....ex. closing out a bunch of work items and having it reflect on your "Remaining Work" reports) you can change the rate at which the datawarehouse is updated.

The warehouse is updated on a timer so in order to improve the turn around for your reports (or more importantly if you need to pull some reports from some data which has not been updated in the warehouse) then you can modify the update interval by calling this webservice.

Changing the Interval Setting

In Internet Explorer, open the following URL:

http://<tfsserver>:8080/Warehouse/v1.0/warehousecontroller.asmx?op=ChangeSetting

where <tfsserver> represents the name of the Team Foundation Server. A page that contains two boxes labeled settingID and newValue opens.

In the box labeled settingID, type RunIntervalSeconds.

In the box labeled newValue, type the new interval time in seconds.

Click Invoke to change the setting.

Security

To perform this procedure, you must be a member of the Administrators group on the Team Foundation application-tier server. For more information, see Team Foundation Server Permissions.

Manually Kick Off the DataWarehouse Update

1. Go to http://localhost:8080/Warehouse/warehousecontroller.asmx using a browser on the app tier.

2. Click the ‘Run’ link.

3. Press the ‘Invoke’ button.

This will trigger a refresh of the reports.

One of the common gripes about Team Foundation Server is that fact that it doesn't support out-of-the-box continuous integration. Well Im sure the team had their reasons to exlude this feature in the first release, but hopefully we will get this in a future release. Until, then we will to come up with something on our own. Ben Waldron addresses these concerns in his Agile Development MSDN article on TFS and Continuous Integration.

Arron Hallberg has a really interesting post on his blog on how to add a custom task to the Team Foundation Build Process. The possibilities of this type of extensibility which most areas of TFS have out of the box are truly amazing.

I have worked with a few code generation tools in the past, Wilson ORMapper, LLBLGen Pro, and now CodeSmith and immediately I thought how great it would be to automate these code generation tools into the build process. Ill probably take a stab at this very soon.

For some reason we started getting the error TF42026 when we attempted to execute our builds. I found this great blog post from Tom Wisnowski which gave a step by step checklist of things to check in order to resolve the issue.

Turns out our this error was being caused from the fact that our Team Build Service was not running.

2. Make sure the Team Build Service is running. Open the services MMC snapin and look for Team Build Service. Make sure the service is running. Also note the account that the service runs as; you will need it for the next step

There are a number of great features in Microsofts Team System Suit and Team Foundation Server components. Of course there are the obvious advantages for the automated, process level, toolset which we gain with the integration of the numerous Microsoft components (Sql Server, Reporting Services, Sharepoint Services, Visual Studio 2005), but the customization of the framework is great as well.

The obvious benefits for TFS is can be found from the top down. Upper management has a newfound lookout tower over all of their projects, project management has more control over the project, and the developers have all of the new cool tools without all of the manual work. However, the customization of the TFS work items, policies, and practices, in my opinion, is will be what standardizes its use across all the industry.

That being said, I found some great blog posts on customizing the checkin policies:

Basic overview of customizing checkin-polices from MSDN.
http://msdn2.microsoft.com/en-us/library/ms181281....

Marcel de Vries has a great post describing an overview of the building a new policy.
http://blogs.infosupport.com/marcelv/pages/CustomP...

Some code samples from another post.
http://blogs.infosupport.com/marcelv/pages/CustomP...

And yet another .zip containing the source and solution for a comment required policy.
http://blogs.vertigosoftware.com/teamsystem/archiv...

So today I installed Team Foundation Build on our Team Foundation Server. Due to the fact that our team size is less than 25 people we decided to go with a single server installation. As of right now, we only have a single project in TFS with only 3-5 active users at any given moment. That being said, the installation for the Build server was cake which is more than I can say for all the hoops that I had to jump through in order to install of the components for TFS. After the installation, I created and ran a standard build, but the build failed.

Error Message:

Solution: , Project: <YourSolutionName>, Compilation errors and warnings

<BuildLocation>\<WebApplicationProject>.csproj(477,11): error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Turns out that this is a known Web Application Project issue.

Issue 6 - Using TFS Team Build
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.

Additionally, if you have an older version of a Web Application Project, you will need to add the WebApplication.targets line (shown in blue and bold) after the normal CSharp.targets or VBasic.targets line in your .csproj or .vbproj file (all new or newly migrated projects will have this line automatically).

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

After copying the Microsoft.WebApplication.targets file the build worked perfect.

Ever since I began working with Visual Studio 2005 I have been making all of my web projects with the Web Application Project Add-In, it seems that one can easily forget that there were are a number of known issues with this great Add-In.