But it works on my PC!

A common work item type (WIT) edit in TFS is to limit the list of names shown in a combo to the users assigned to the project i.e. the members of the Team Projects Contributors and Project Administrators groups.

This is done by editing the WIT either via your favourite XML editor or the Process Template Editor (part of the power tools). You edit the Allowedvalues for the field you wish to limit such as the Assigned To as shown below,

Which gives the following XML behind the scenes (for those using XML editors)

<ListRule filteritems="excludegroups">
  <LISTITEM value="[Project]\Contributors" />
  <LISTITEM value="[Project]\Project Administrators" />
  <LISTITEM value="Unassigned" />
</ListRule>

Notice that Expand Items and Exclude Groups are checked. This means that the first two lines in the list will be expanded to contain the names in the groups, not the group names themselves.

A small gotcha here is that if either of the groups are empty you do see the group name in the combobox list, even with the Exclude Groups checked. Team Explorer does not expand an empty list to be a list with no entries, it show the group name. So you would see in the combo something like

• [MyProject]\Contributors
• John
• Fred
• Unassigned
  

where John and Fred as project administrators and the [MyProject]\Contributors group is empty.

This should not be a serious issue as in most cases why would you have a Team Project with no contributors or administrators? However it is conceivable with more complex security models you might see this issue. if so make sure each group in the list has at least one member, again if it does not have any members do you really need it?

I have just posted new VirtualPC activity documentation for TFS 2010 Community Build Extensions. This has been a really nasty set of documentation to write as getting this activity running raises a lot of issues over COM security; thanks to Rik and Andy (our SharePoint specialists at Black Marble who are therefore used to COM problems!) who helped get to the bottom the issues.

The best thing I can say about this VirtualPC activity (and I wrote much of it) is don’t use it. Much better to use the Hyper-V one it is far more flexible, allowing control of remotely hosted VMs, or even better use TFS Lab Management

Today I have posted a few more pages of the getting started documentation for the TFS 2010 community build extensions. This is an on-going task, I hope to get a few more written when I get a chance. I am writing the documentation in no obvious order, so let me know if any specific activity is in more need of some introductory level documentation than others.

Mike Fourie has just announced that we’ve just shipped the second stable release of the Community TFS 2010 Build Extensions. Well worth a look if you need to customised your TFS 2010 build with any of the following

There is a good chance if you are using TFS that you will want to create some custom reports. You can write these in Reporting Services via BI Studio or Excel, but I wanted to use Report Builder, but could not see the Report Builder button on this Reporting Services menu

The problem was multi-levelled

First I had to give the user access to the Report Builder. This is done using folder property security. I chose to give this right to a user (along with browser rights) from the root of the reporting services site

But still no button. Forums and blog posts then talk about changing options on the ‘Site Settings’ menu, the above screenshots shows that this is also missing from the top right.

To get this menu option back, I had to run my browser as administrator and then this option appeared. Turns out that the TFS Setup user I was using  had not been made a Reporting Services site administrator, just a content administrator.

But still this was not enough, I also add to add users as System Users to allow the Reporting Services button to appears. So my final Site Settings > Security options were

Once all this was done I got my Report Build button and I could start to write reports.

Robert Hancock, another one of Black Marble’s ALM consultants, has started blog technical tips on this blog server. You can find Robert’s new blog here or the aggregate feed of all Black marble bloggers here

When using TFS2010 It is possible for a build agent to appear to be ready (or so the status label says) but the icon stays in the off state.

This is usually due to a couple of broad categories of error, you can find out which by checking the Windows event log.

The build agent cannot communicate with the controller

In the event log you see something like

Service 'Default Agent - win7' had an exception:
Exception Message: There was no endpoint listening at http://controller.mydomain.co.uk:9191/Build/v3.0/Services/Controller/1 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. (type EndpointNotFoundException)

This should not happen too much within a corporate LAN, though it is always worth checking to make sure any PCs firewalls are not blocking the port used by the build service (9191).

However if you are trying to use build agents that are not directly on your LAN/AD (see this lovely clear blog post on how to set up using a non-domain joined build agent) there is a good chance you will not have DNS working as expected. So make sure the controller can resolve the name of the agent and vice versa. For me this meant editing HOST files and checking name resolved with good old PING.

Custom assemblies have un-resolved dependencies

Whilst writing documentation for the community extensions for TFS build I had the this problem. I had the custom assemblies path set for the build controller. This meant when the build agent starts it downloads any custom assemblies from the specified folder. Some the community extensions assume that the build agent has features/application installed such IIS or Visual Studio. I had assumed any missing dependencies would only show up when you tried to use a community activity in a build. However, this is not the case it seems. During the agent load some checks are made. In the event log I saw errors such as

Service 'Default Agent - win7' had an exception:
Exception Message: Problem with loading custom assemblies: Could not load file or assembly 'Microsoft.VisualStudio.Shell, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. (type Exception)

or

Service 'Default Agent - win7' had an exception:
Exception Message: Problem with loading custom assemblies: Could not load file or assembly 'Microsoft.Web.Administration, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (type Exception)

To resolve these issues I installed the features and application on the agent needed by the build extensions. The other option would be remove the custom extension assemblies that had the dependencies, assuming you did not need them.

So hopefully this post should give you a pointer on fixing strange ‘has it started or not’ states that the build agent can get into

At the Build  conference today the preview of TFS on Windows Azure was announced. All the attendees of the conference have been given access codes for the preview. If you did not make it to Build have a look at  Brian Harry’s blog for details of how everyone else can get access to the preview.

If you are editing a TFS process template you have the choice editing XML files or using the Process Template Editor within the TFS 2010 PowerTools. Unfortunately neither is fool proof. You can make errors than means the revised template does not fully work.

The worst of these errors will be picked up when upload the process template to a Team project Collection as during this process the XML is validated.

However, this will not find everything. Today after uploading a new process template I found I could not see two of my revised work item type in the list when I tried to create a new work item.

The best way I found to work out the problem was to try to import the .WIT file (from your local copy of the process template) again using either the Visual Studio –> Tools –> Process Editor –> Work item Types –> Import from File, or the command line tool WITIMPORT

In my case I then got the far more useful error

--------------------------
Error
---------------------------
Error importing work item type definition:

TF237094: Field name 'Priority' is used by the field 'Microsoft.VSTS.Common.Priority', so it cannot be used by the field 'MyNewProcess.Priority'.
---------------------------
OK  
---------------------------

This gave me much more information to fix my problem

If you use the database unit testing feature of VS2010 there is a good chance you will want to run these tests on more than one PC and probably the build server. The issue is that these different PC will need different deployment paths and SQL connection strings. Luckily there is a feature to address this, as detailed on MSDN. Basically the test runner swaps in a different config file based on either the PC name or user running the tests.

This all seems straight forward, but when I followed the process and ran my tests they failed

The most useful error is found if you get the test run details (the button highlighted in green). You can see that it found the file replacement config file but failed to parse it giving the error

An error occurred while reading file C:\…\TestResults\fred_PCNAME 2011-09-12 22_33_11\Out\buildbox.dbunittest.config : Expected to find an element.

[It is work noting here it is easy to forget to make sure the buildbox.dbunittest.config is deployed to the test folder as detailed on MSDN. If you forget this you get a file not found error not an ‘expected to find an element’ error]

So I checked my buildbox.dbunittest.config file to look for typos. The MSDN instructions say to copy the app.config and make your edits, but then goes onto mention after editing it should resemble.

<DatabaseUnitTesting> 
       <DatabaseDeployment DatabaseProjectFileName="..\..\..\Sources\UnitTest\UnitTest\UnitTest.dbproj" Configuration="Debug" />
       <DataGeneration ClearDatabase="true" />
       <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\SQLEXPRESS;
                       Initial Catalog=UnitTestB;Integrated Security=True;Pooling=False" CommandTimeout="30" />
       <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\SQLEXPRESS;
                       Initial Catalog=UnitTestB;Integrated Security=True;Pooling=False" CommandTimeout="30" />
</DatabaseUnitTesting> 

It should NOT include the <?xml version="1.0" encoding="utf-8" ?>, <configuration> or <configSections> tags. This as been stressed in some forum posts. However even when I made sure my buildbox.dbunittest.config first line was <DatabaseUnitTesting> I still got the same error.

Turns out the issue was that I had leading white space before the <DatabaseUnitTesting>, once these were removed the test ran as expected.