The next release of the MSBuild Extension Pack will offer IntelliSense for all tasks. It’s a small but helpful addition which makes using the tasks that little bit easier.

We will also ship an IntelliSense schema file for the Team Foundation Build Tasks.

In generating this schema file, a few undocumented properties were discovered that you may find useful:

• Get: TeamFoundationServerUrl, Overwrite
• Label: TeamFoundationServerUrl, Scope
• SetBuildProperties: LogLocation, SourceGetVersion

Required parameters have ‘REQUIRED.’ as a prefix in the tooltips shown.

Unfortunately a bug exists in Visual Studio 2008 & SP1 which means that you will partially lose IntelliSense in the IDE if you use schema documented tasks after undocumented tasks. Here is a quick repro:

This repro uses the following simple sample

1. <Project DefaultTargets="IntelliPain" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
2.          
3.     <Target Name="IntelliPain">
5.         <UnDocumentedTask AProperty="a"/>
7.     </Target>
8. </Project>

Step 1

• Start typing at Line 4.
• IntelliSense on the available tasks is seen.

• Continue typing at Line 4.
• IntelliSense on the available tasks parameters is seen.
• CTRL-SPACE can be used to display the parameter IntelliSense if it is not shown.

Step 2

• Start typing at Line 6 (i.e. BELOW the task which has no associated schema).
• IntelliSense on the available tasks is seen.

• Continue typing at Line 6
• IntelliSense on the available tasks parameters is NOT seen.
• CTRL-SPACE can NOT be used to display the parameter IntelliSense.

This bug has been reported to Microsoft but I don’t know when we can expect a fix. A workaround is to create documentation schema files for all the tasks you write (and use if they don’t already have them). There is some guidance for doing this here, and you will find more guidance in the next version of the MSBuild Extension Pack help file.

If you would like to try out these schema files now, you can download pre-release versions from the CodePlex site.

UPDATE: Please see MSBuild Extension Pack

The FTDSourceAnalysis task is now available again. This task works with Source Analysis 4.2. A version for StyleCop 4.3 will be made available in the FreeToDev MSBuild Tasks Suite soon...

UPDATE: Please see MSBuild Extension Pack

24 July 2008 UPDATE: Part 2 is available.

I’ve lost count of the number of blog posts, forum questions and internal emails that I have seen regarding problems with versioning assemblies in TFS. I’ve made various responses to them and in many said I would put together some thoughts to clarify my thinking on the matter... I’ve finally got round to doing it...

The Problem

I believe the root cause of the problem is that many users have tried to migrate their existing versioning logic and code to work with TFS, blinded by the wealth of functionality that TFS has brought to the development process.

The truth is that TFS provides the basic fundamentals of iterative versioning out the box.

Versioning Assemblies

Let’s start with some basic fundamentals. What’s a version number? There are two version numbers in .net, the AssemblyVersion and the AssemblyFileVersion. Both follow the same format:

<major version>.<minor version>.<build number>.<revision>

My first piece of general advice is that you don’t keep the two in sync. The assembly version should rather be of the format:

<major version>.<minor version>.0.0

The main reason for this is that strong name signatures include the assembly version, which means that if you release an updated assembly, the code that references it will need to be updated too (unless you go the policy route, but let’s keep things simple).

The AssemblyFileVersion is the attribute that should be updated with every build you perform, and therein lays the question. How?

I would estimate that in 99% of builds, the format of the build number will be

<Fixed major version>.<Fixed minor version>.< Calculated build number>.<Iterative revision>

The Fixed parts are easy and they will most likely equate to those used in the AssemblyVersion. The calculated part is really up to you. It could be a date format, the number of days since a give milestone etc. The iterative part is where the trouble lies.

Let’s look at some tools for versioning. In the past, before TFS, you may have used the SDC Tasks for versioning, or your own bespoke solution. With the first release of TFS, a popular solution was, and still is, the AssemblyInfo Task. All these solutions need to provide the same essential logic.

They need to calculate your build number and provide a unique incremental value for every build. To ensure that the incremental value is unique, most versioning solutions check out a file, alter it and check the file back in.

This is the operation that causes the most problems. When I first used the AssemblyInfo task, I encountered numerous painful ‘cannot determine the workspace’ errors. I could easily resolve those issues today, but with little experience and understanding of TFS back then, I and many others felt the pain. If that error didn’t catch you, then you were likely to be caught by checkin policies or duplicate attributes. All issues can be resolved, but too many people have had a hard time with this task.

So, if you managed to get around the AssemblyInfo task issues, or your own problems with creating a task that checked out a file, incremented the value and then checked it in again, well done... and welcome to contiguous merging issues! TFS 2005 / 2008 don’t support multiple pending merge entries for a single file, so you have to perform contiguous merging. This isn’t a big issue with versioning tasks, however the problem with continuously checking out and in the versioning files(s) is that you get loads of noise on the pending merges table and if you do merge multiple version files, you will likely have to manually resolve the final version.

Many people have questioned why Microsoft didn’t release a basic versioning task with TFS, and in fact it appears that the next version of TFS may include such functionality. But why wait? The functionality is already there, it just needs to be used.

Don’t do it

My second piece of general advice is don’t check your versioning files in and out during the build process. As discussed above, it creates noise and hassle with merges. As long as you’re versioning logic can be related to the TFS Build Number, I see no benefit in having this source control operation take place. Stop the obsession!

The Solution

TFS provides a build number for every build it initiates. The format is

<build name>_<year><month><day>.<revision>

e.g.

MSSDCDaily_20080402.1

To accomplish versioning, use the <revision> part of the build number. TFS will provide an incremented revision for every build, whether the previous build succeeded or not. All you need to do is provide a task that takes the build number as input, then emits your version number as output. The logic within the task is up to you.

The lightweight TFS Versioning Tasks provide functionality to easily create builds with a calculated build number in a date or elapsed format.

Because your build is based on the build number, you can easily locate the label associated with the build.

In summary

• Don’t increment the AssemblyVersion
• Do increment the AssemblyFileVersion
• Don’t perform source control operations for versioning
• Do base your build number iteration on the TFS Build Number
• Do base your build number calculation on the TFS Build Number

I hope that clarifies things...FTD

There will be a lot more to say about this library in the coming weeks. The MSBuild Extension Pack is the successor to the FreeToDev MSBuild Tasks Suite.

The suite provides many enhancements over the FreeToDev MSBuild Tasks Suite. Please review the Help file for a migration overview for existing FreeToDev MSBuild Tasks Suite users and much more.

You can access the MSBuild Extension Pack via www.msbuildextensionpack.com or http://www.codeplex.com/MSBuildExtensionPack