But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Empty groups not being expanded in a combobox for a TFS work item

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,

image

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?

Tempted by the new Kindle?

I am back on the should I buy a Kindle train of thought. Todays announcements are certainly interesting, I am not talking so much about the new Kindle Fire, but the new entry level version and the Touch. For me the tempting feature is still the E-Ink and battery life.

The point is I have got used to reading on my phone, a Kindle might be easier on the eye, but it is more kit to carry, and I just don’t think I want to carry any more things.

Just posted VirtualPC activity documentation for TFS 2010 Community Build Extensions

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

Upcoming Black Marble event on Windows 8

In case you did not make it to the Microsoft Build Conference, Black Marble are running a pair of free events in Leeds on the 12th of October on Windows 8 and the other announcements made in Anaheim earlier this month.

The morning session is focused on the IT pro side and the afternoon on development, so why not make a day of it?

To get more information, and to register for these free events, have a look at http://www.blackmarble.co.uk/Events

Syncing the build number and assembly version numbers in a TFS build when using the TFSVersion activity

Updated 27 July 2013 - Here is a potential solution

Update 27 Sep 2011 – this seemed such as good idea when I initially tried it out, but after more testing I see changing the build number part way through a build causes problems. The key one being that when you queue the next build it is issued the same revision number [the $(Rev:.r) in the BuildNumberFormat] as the just completed build, this will fail with the error

TF42064: The build number 'BuildCustomisation_20110927.17 (4.5.269.17)' already exists for build definition '\MSF Agile\BuildCustomisation'.

This failed build causes the revision to increment so the next build is fine, and the cycle continues. Every other build works

After a bit more thought the only option I can see to avoid this problems is the one Ewald originally outlined i.e. a couple of  new activities that are run on the controller, one to get the last assembly version and the second to override the build number generator that are run prior to everything else.

So I have struck out some bits of the post and made it clear where there are issues, but I wanted to leave it available as I think it does show how it is easy to get to point that you think is working, but turns out there are unexpected problems

[Original content follows]


I was asked recently if it was possible to make the TFS build number the same format as the assembly build number when you are using the TFSVersion community extension. The answer is yes and no; the issue is that the build drop location in the standard build process template is create before any files are got into the workspace from source control. So at this point you don’t have new version number, a bit of a problem.

A detailed description of one approach to this general problem can be found in Ewald Hofman’s blog on the subject, but to use this technique you end up creating another custom activity to update the build number using your own macro expansion. Also there will be some major workflow changes to make sure directories are created with the correct names.

<Following Does not Work>

There following instructions do not give the desired result for the reasons outlined at the top of this updated post

I was looking for a simpler (lazier) solution when using the TFSVersion activity and the one I came up with to just update the build name, and do it after the drop directory was created. So that I did not end up with two completely different names for the drop folder and build I just append the version number to the existing build number. This is done by re-running the Update Build Number activity. I added this new activity to example workflow logic from the TFSVersion documentation, ending up with something like

image

where the Update Build Number has the following properties

image

So we just append the newly generated version number to the existing build number.

string.Format("{0} ({1})", BuildDetail.BuildNumber , VersionNumber)

Note you can’t use the BuildNumberFormat.in this string format as this string contains the $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r) text that via macro expansion is used to generate the build number. The problems if this expansion if used in this string format you get the error

The revision number $(Rev:.r) is allowed to occur only at the end of the format string.

So it is easier to use the previously generated build number.

This also has the effect that drop folder retains the original name but all the reports contain the old folder name with the generated build number in brackets, and the Open Drop Folder link still works

image

I reasonable compromise I think, not too much change from a standard template.

Does not work as only alternate build work, see top of post

</Following Does not Work>

New Release of the Community TFS 2010 Build Extensions

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

  • AssemblyInfo
  • BuildReport
  • BuildWorkspace
  • CodeMetric
  • DateAndTime
  • Email
  • File
  • GetBuildController
  • GetBuildDefinition
  • GetBuildServer
  • GetWebAccessUrl
  • Guid
  • Hello
  • HyperV
  • IIS7
  • ILMerge
  • InvokePowerShellCommand
  • nUnit
  • QueueBuild
  • RoboCop
  • SqlExecute
  • StyleCop
  • TFSVersion
  • VB6
  • VirtualPC
  • VSDevEnv
  • Wmi
  • WorkItemTracking
  • Zip

Stupid gotchas on a SQL 2008 Reporting Services are why I cannot see the Report Builder Button

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

image

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

image

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

image

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