Fixing TFS reports after an upgrade/migration to TFS 2008

Microsoft has made quite a few changes to reports in TFS 2008. As you can see form the table below in TFS 2008 we do not only have 6 new reports, but some of the existing reports have been modified/removed (new reports are in red, removed reports are in orange).

TFS 2005 default reports

TFS 2008 default reports

Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work

 

Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Exit Criteria
Issues List
Load Test Detail
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work
Work Item with Tasks
Work Item with TestResults
Work Items

This means that when you upgrade/migrate to Team Foundation Server 2008, your reports will no longer work as the schema has changed. To resolve the issue you need to download the new process template (http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx) and add or update your reports on TFS server.

To add new report:

  1. Go to your Reports server (http:// [SERVERNAME] /reports)
  2. Click on Upload file
  3. Browse to the report file (.rdl) you want to upload and click OK to upload
  4. Click on newly uploaded report file and click on Properties
  5. Set up data sources by clicking on Data Sources (Don't forget to click Apply button)
  6. Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
  7. Click on View to make sure that report is displaying properly

 

To update existing report:

  1. Go to your Reports server (http:// [SERVERNAME] /reports)
  2. Click on report that you want to update and click on Properties
  3. Click on Update
  4. Browse to the report file (.rdl) you want to upload and click OK to upload
  5. Make sure that data sources are configured properly by clicking on Data Sources (Don't forget to click Apply button)
  6. Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
  7. Click on View to make sure that report is displaying properly

Note: You will have to update reports for each TFS project

Cleaning up your TFS Build Server

The Team Foundation Build Server at one of our clients was getting out of hand. We set up continuous integration so we are getting a lot of builds per day. The server had hundreds of builds that we just didn't need hanging around anymore. We asked our IT guy extraordinaire, Max if he could write us a script to automate the cleanup of TFS Builds. He rose to the challenge and now we have one.

He wrote the VB Script attached to this post. I tried it out on the server last Friday and it worked great. Here is the command to call it.

cscript TFSBuildCleanup.vbs http://<Server>:<port> <Project> <Build Location> <BuildType> <Days>

  • Server = Team Foundation Server
  • Port = TFS port
  • Build Location = Folder that contains the builds on the server (ie: c:\Builds)
  • BuildType = Name of the build Type to remove
  • Number of days of build to keep. If you put seven it will remove all the build 8 days and older.

I set it up as a task on the build server to run each night.

I hope it's useful to someone out there.

Visual Studio 2008 to ship by end of month!

In case you didn't catch this S. Somasegar announced today during his TechEd Developers Keynote in Barcelona that Visual Studio 2008 will ship by the end of this month (November!). Yeah! Most people were counting on this before the end of the year which mean December or early January so this comes as a nice surprise.

We're talking about some cool technology:

  • Visual Studio 2008 (all editions)
  • Team Foundation Server 2008
  • .NET Framework 3.5
  • Language Integrated Query (LINQ)

Now of course the best feature in Visual Studio 2008 is multi-targeting. This features allows you to continue to develop .NET 2.0 or 3.0 applications without migrating to 3.5. There are lots of great features if Visual Studio 2008 - even if you don't move to .NET 3.5:

And if you are a Team System User

  • SharePoint 2007/WSS 3.0 or MOSS support
  • Simplified Installation
  • Better Offline Support
  • A bunch of other stuff including Power Tool Rollups.

And don't worry - you can install VS 2008 side by side with VS 2005.

Ignoring Static Analysis Warnings, Centrally

via Soma

Back in the days of fxCop, (before we had to pay for code analysis in Team Developer) if you didn't like an error/warning, you could have your request to ignore said message in an external central file.

With the advent of Visual Studio Team Editions for Developers 2005, suppressions were stored as attributes in front of blocks of code. Look on the bright side we were told - now you could see your suppressions inline with your code, versioned alongside, etc. But we lost some things with this as well. Now if you were doing major code sweeps adding suppressions, you would be touching lots of files, creating some unnecessary code churn.

Another scenario may involve a given developer doing a sweep for localization, or security, compliance, etc. In fxCop, different developers could have different settings & suppression files.

Well, Visual Studio 2008 to the rescue. Code Analysis will now give us back this capability.

One of the little pet projects I'm working on is to take a code analysis pass, and cross reference that with a change set. The goal is to generate a report of obvious warnings related to the code I'm churning. We can't be perfect here as sometimes code analysis will return an error to a line of code you didn't change, but it is indirectly caused by that. The only way to truly get a clean report would be to do a code analysis before & after the checkin - that might be too much. But this would definitely be a great report for a build - to compare code analysis passes on previous builds.

Test Deployment

DeploymentItem Attribute on a VSTS TestMethod

Did you know there are two ways to Deploy files to be used when executing unit tests in VSTS.

 

You can added them to the .Testrunconfig:

 

 

Or using the DeploymentItem attribute on the TestMethod:

 

 

[TestMethod,DeploymentItem(@"Bin\fr-CA\Thermo.Automation.Foundation.Tests.resources.dll","fr-CA")]

public void Multilanguage()

{

    Message msg = Message.Retrieve(Messages.Multilanguage);

    msgServ.Post(msg);

    Assert.IsTrue(msgServ.ValidateMessageReceived("English message"));

 

    Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr-CA");

 

    Message msgFr = Message.Retrieve(Messages.Multilanguage);

    msgServ.Post(msgFr);

    Assert.IsTrue(msgServ.ValidateMessageReceived("French message"));

}    

 

Snagit and TFS

Two great tools come together to make our lives easier.

 I have been a fan of Snagit for many many years, and more recently Camtasia, both from Techsmith. Now snagit has a hook into Team Foundation Server, allowing you to create a Work Item from a Snapshot of a screen. Using the tried and true features of snagit to capture a portion of your screen you can now use the newly added Team System tool bar item to create a Workitem and automatically attach the screen shot to it.

TechSmith has a Camtasia demo here so you can see it in action.

Thanks Andre

Looking for Mr (or Ms) GoodDeveloper

Business has been booming of late at ObjectSharp. Don't know whether it's the weather or the business cycle, but our recent company barbeque had more new faces that I've seen in many years. And we haven't lost any of the old faces either.

And yet it doesn't seem to end. At the moment, we're looking to add some consultants to our team. Specifically, we have the need for someone with Windows Forms experience, either in creating commercial-grade user interfaces on their own or with the CAB application block.

If you (or someone you know) has that experience and is looking to join a fun team of top-notch developers, drop me your (or your friend's) resume. You'll get a chance to work on projects that use cutting edge technology. You'll learn about (and sometimes use) technologies that aren't yet available. And, if you have the interest, we have six MVPs on staff to help you get your own designation.

If you don't fit into this skill set, fret not. There will be others coming along in the very near future. Just keep your eye tuned to this blog. 

VSTS unit testing and the .VSMDI

If you have done any serious unit testing with Visual Studio Team System and tried to include these tests in your Team Build you will have come across issues with the .VSMDI. It might drive you crazy until you completeley understand what is going on. Lets see if I can explain the situation with a series of truths.

  1. The .VSMDI file is Test Meta Data
  2. Each Solution can have only one .VSMDI
  3. The .VSMDI stores, amoung other things, test lists created using Test Manager
  4. Test lists are required to execute tests in a Team Build
  5. The .VSMDI must be checked into source control for this to work
  6. VS for Developers does not come with Test Manager
  7. A solution can have multiple .testrunconfig files
  8. The active .testrunconfig is stored in the .VSMDI
  9. When a developers switches to another .testrunconfig it will change the .VSMDI

All these truths together mean that everyone on a team including the Build server sharing one solution (which I see happen a lot) is a pain in the ass.  

So how do you each have your own .testrunconfig without messing up the build server. There are plenty of blogs and forum entries out there complaining of this in one way or another.

From what I can tell there are a couple of things you can do.

  1. Download and use the TFS PowerToys TestToolsTask so you can run tests in a build without test meta data files and test lists. The problem with this is it's more difficult to include only the tests you want executed on the build server. Not impossible but not as easy as using test lists.
  2. Create a solution for the Build Server to use. It can have it's own test run config and test lists .VSMDI ( You still need team suite or VS for testers to create them) of course all the developers should have their own Solutions also. This can have it's own headaches on a large project when many VS Projects make up the solution. As developers add projects to their solution they have to make sure everyone else knows as well as the build server solution.

I hope they address this in a coming release, I'd like it to be more transparent to the developer.

EnergizeIT

I am speaking today at EnergizeIT. I'm doing a talk on unit testing with VSTS at 3:30. I'll be talking to the kids about some of the things to watch out for when doing unit testing in VSTS, as well as some of the really nice features.

I attached my demo apps to this Blog entry if you are interested.