Today I bumped into a solution for deleting deleted Team Projects (yip, that’s right: deleting Team Projects that should have been already deleted). A while ago we noticed that Team Projects in TFS2008 SP1 that were deleted with TFSDeleteProject.exe were still visible in the Source Control Explorer and re-running TFSDeleteProject.exe for the same Team Projects resulted in an error message that the Team Project could not be found on the Team Foundation Server.

But due to this entry in the TFS forum I was finally able to remove the Team Projects from Source Control Explorer as well.

Solution:

• Create new Team Project with exactly the same name as the Team Project that wasn’t completely deleted and specify the option to not create the version control folder.
• After the Team Project Creation wizard finishes, you need to run TFSDeleteProject.exe for the newly created Team Project.

No sign anymore of the deleted Team Projects in Version Control! Sounds logical?!

1. Para copiar el directorio completo utilizaremos una bibilioteca de tareas para TFS Build: SDC Tasks, ya que la tarea Copy que posee MSBuild no es lo suficientemente potente para este escenario.

2. SDC Tasks se puede descargar desde http://sdctasks.codeplex.com/ y luego debemos copiar el contenido de la release al directorio de MSBuild [C:\Program Files\MSBuild].

3. Editamos una definición de build, en este caso llamado [Hola Mundo Build]. Nota: Podemos utilizar este post como ejemplo para editar un build.

4. En la cabecera importamos el archivo que nos permite utilizar las SDC desde la definición del Build, en este caso la línea 5.

5. Agregamos un nuevo Target, en este caso el que se ejecuta después de copiar los archivos de la compilación; y dentro del mismo utilizamos la tarea Fodler.Copy (línea 13) para copiar el resultado de los tests de una build al directorio FTP, utilizando además el número de la build para identificar los resultados.

6. Para mostrar los pasos de ejecución del build, utilizamos BuildSteps (ver líneas 3 y 15; para referencia ver este post). De esta forma, cuando se ejecuta un build, podemos ver lo siguiente.

7. De esta forma, cada vez que se ejecute un build y se generen resultados de tests, los mismos se copiarán a la carpeta C:\FTP.

# re: [TFS2008] HowTo: Copiar el resultado completo de un build (assemblies, test results, etc) a una carpeta determinada

También es posible usar de forma mas directa la herramienta robocopy, viene por defecto en W2008 Server (creo que tb en 2003).

Robocopy mucho  mas robusta en la copia, por ejemplo cuando es una unidad de red que pueda estar no siempre compartida, y se quiere reintentar 4 veces la copia, esperando 2 segundos, excluyendo las subcarpetas que se llamen bin se puede usar el siguiente comando

<Target Name=”PackageBinaries”>

<Exec Command=”Robocopy.exe $(BinariesRoot)\Release\_PublishedWebsites\carpetaOrigen \\Servidor2\CarpetaDestino /MIR /R:4 /W:2 /TBD /XD bin” IgnoreExitCode=”true” />

</Target>

Se puede usar en evento PackageBinaries, o AfterDropBuild segun las necesidades.

Un saludo y gracias a Bruno. Fuente Oficial:  Aquí

This week at TechEd in Berlin, Hans asked for some interesting ALM / TFS books. This is a quick random list of the latest books I know about:

• Team foundation Server in Action
• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
• Professional Team Foundation Server
• Software Engineering with Microsoft Visual Studio Team System
• Visual Studio Team System: Better Software Development for Agile Teams
• Managing Projects with Microsoft Visual Studio Team System
• Pro Visual Studio Team System Application Lifecycle Management
• Pro Visual Studio Team System with Team Edition for Database Professionals

Feel free to add some more books to the list!

Note that there is also a paperback version available of the TFS Guide: Team Development with Visual Studio Team Foundation Server, written by Microsoft Patterns & Practices. The online version can be found at CodePlex: TFS Guide.

If you are looking for the online MSDN documentation, point your favorite browser to the Team Foundation Server Developer Center.

There will also come some new books on VS2010: Professional Visual Studio 2010 Team System: with Team Foundation Server 2010, but I think that the name of the book will still change. Martin Woodward also mentioned that he’s writing on a new Team Build book for VS2010 and I’m sure that there are others under construction. To be continued!

So, you are playing around with VS2010/TFS2010 and you have some remarks, suggestions, bugs, … Please go the Microsoft Connect site for product feedback and bug reporting.

Today I filed a suggestion for the next release of Team Foundation Server: Build Definition History. Unfortunately it’s still not possible to view history of changes made to the Build Defintion: “Drop Location”, “Build Agent”, “Trigger”, … On the Microsoft Connect site, you can easily look up other wanted featured and vote for them … but first vote for my suggestion!

Since a few weeks, there’s also a feedback survey running on Microsoft Visual Studio 2010 and the .NET Framework 4 Beta 2. If you care about the product and want your voice heard, please take some minutes to complete this online survey!

I’ve got a small server at home where I also run TFS on for my personal projects and for playing around with it to try some stuff.

Since TFS 2010 Beta 2 is available I wanted to work with VS2010 and TFS 2010. As I’m just a geek who wants to play around with it at home, I didn’t plan how to do this change etc. Because I didn’t care much about the history in source control, I decided to simply reinstall my server (I was already planning to do this as I wanted to use SQL Server 2008).

All went pretty well when installing and configuring. But then yesterday I wanted to add all the source I had on my local machine to the source control. And then the probleem started.
I got the message stating that I already had a workspace mapping for the local directory. WOOPS…. And I couldn’t connect to my old TFS server anymore because I destroyed that completely .
So I hadn’t got a clue what to do, because for as far as I know, the workspace mappings were registered at the server, not locally. I already removed the source control bindings from the solution, but that was not enough. Still getting the error.
It took me quite some time to find that the workspace mappings are also cached on your local machine. I finally found the mapping mentioned in the folder C:\Users\[USER]\AppData\Local\Microsoft\Team Foundation\2.0\Cache\versioncontrol.config. I deleted it from there and I could finally add my source to source control again.

Lesson learned: Think twice before doing a format on my server and try to do some planning / impact analysis before throwing things away, even when I do it on my ‘playing around environment’.

I fought for a couple of minutes with this error and I thought to share with you my solution.

The error was on my build machine which wasn’t having Windows SDK and I wasn’t planning to install it either.

I was having HKLM\SOFTWARE\Microsoft\Microsoft SDKs\.NETFramework\v2.0 key and the InstallationFolder key with the value C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\ so I thought about adding the key that was normally generated by Windows SDK.

So, I added HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A key with the InstallationFolder key pointing to the same value as above and copied the missing sgen.exe into the bin\ folder under the above mention location.

I queued a new build a everything worked like a charm.

I hope this helps,
Bogdan

Today we ran into a strange problem. The nightly build had failed when trying to empy the working folder on the build server with a message like “cannot remove file ‘data.coverage’ because it is being used by another process”.

Very strange because nothing special was going on on the build server. For some reason the process VSPerfMon.exe had continued running. I killed the process and started the build again. Now the build runs again and didn’t have the problem anymore.
Strange… Looks like the test host just crashed or something like that. No idea (yet) why that happend. I’ll update the post if I find out why this happened.

If you have the same problem, just kill the VSPerfMon process and clean the directory. Probably the build will run again then.

 
About a year ago I performed a VSTS/TFS assignment for Adam Software, a global software vendor of marketing platform technologies that provide the ability to manage, structure and deliver media between people, processes and systems. This assignment was really fun to do and the customer was really pleased with the result. A few weeks ago, a Microsoft case study was published to put Visual Studio Team System and Team Foundation Server in the spotlight.

In case you still wonder : setting up a robust and reliable enterprise software development environment with Team Foundation Server may be a big investment, but it always pays off. Not only financially! Your development team will also be working with the best tools and processes to do their job. In the long run you might even attract or repel developers just because of the type of development environment you provide as an organisation! For those who worked already in a TFS environment with Version Control, Work Item Tracking and Automated Builds … would you want to go back in time and work with Visual SourceSafe to deliver quality software enterprise applications?

Still looking for a challenging development job where you are able to use the best tools and processes : Adam Software is hiring!

Read more :

• customer testimonial (pdf – english)
• blogpost Michael Vanhoutte (Senior Software Architect Adam Software)l
• blogpost Hans Verbeeck (Partner Evangelist Microsoft Belgium)

 
As promised to the participants of the ALM Roadshow today in Gent, I’ve uploaded the slides I presented :

• Planning your team’s work with VSTS
• Source Control done the right way with TFS
• Test your code in variouw ways with VSTS

Note that these presentations target Visual Studio Team System 2008 (current technology) and not yet the new upcoming release of Visual Studio Team System 2010.

I’ve also uploaded the Product Guide for Visual Studio Team System 2008. This may be interesting for example to know which feature belongs to which client edition of Visual Studio Team System. I always get a lot of questions concerning this topic …

Another general question I got concerning licenses : is it required to have a Client Access License (CAL) to connect to a Team Foundation Server Workgroup Edition? Also taken from the product guide :

Workgroup Edition is provided with Visual Studio Team System 2008 Client Products with MSDN Premium Subscriptions. In addition, CALs are not required for accessing Workgroup Edition.

Feel free to contact me would you require further information!

Update [June 18, 2009]
Video screencasts of the sessions have been uploaded on MSDN Chopsticks :

• Part 1
• Part 2
• Part 3

ASP.NET MVC

CoNatural continue their series on asynchronous search with ASP.NET MVC and JQuery.

Phil has an excellent article about another hidden gem of ASP.NET that allows us to mingle with the page parsing process: PageParseFilter.

Scott Allen show how to build a custom model binder and what are the different issues the arise in different implementations.

Maarten Balliauw adds to the previous list of best practices his very own.

David Hayden has a nice article about working with custom ControllerActionInvoker and overriding CreateActionResult() in order to return JSON results.

Visual Studio 2010

The WebDev Team just published a great article on how we can have a web.config file for each staging environment based on the new transformation features available in Visual Studio 2010.

Channel 9 has another webcast on functional UI testing.

CLR

For a deep dive into ThreadAbortException and how to make it stop using catch clause and Thread.ResetAbort(), go check the CLR Team’s post!

Eric Lippert has another great article that explains that value types being stored on the stack is just an optimization detail performed by the CLR.

C#

Eric Lippert explains how events are raised properly and what are the risks involved with using them inappropriately.

Architecture

Vittorio has another great article about claims and how they work.

Debugging

The Microsoft Support Team has a very cool article about debugging ASP.NET requests at runtime in IIS 6.0.

ASP.NET AJAX 4.0

Bertrand Le Roy has another great tip on how to use JQuery to instantiate Microsoft AJAX components.

Methodologies

The SRLTeam has a great post about bug management.

TDD

Simon Segal has a great post about mocking Entity Framework repositories with Moq.

Team Foundation Server

If you are looking for customizing different aspects of TFS, keep an eye on this blog as it very useful information. Currently they have a nice series of posts on work item customization.

Enterprise Library

Grigori Melnik has some greats news about EntLibContrib: a new release is available (based on the EL 3.1 core) and the future plans include upgrade to the core of EL 4.1.

After merging the solution file while getting the latest version and checking back in, the TFS automatic build triggered by the check-in failed.

The solution was quite simple:

1. I added a dummy file to the solution and checked-in the solution with the new dummy file.
2. I had a successful automatic build.
3. I removed the dummy file and checked-in again the solution without the dummy file.
4. I had another successful automatic build.

I hope this will help others too!

 
You might already have been in the situation where you wanted to unshelve a stored shelveset when having local changes to files that were also changed in the stored shelveset. Out-of-the-box with TFS 2008, this is not possible and you will get the following error dialog :

Your local workspace may not contain pending changes on files that are included in the shelveset. However, there is a way to unshelve with local pending changes. Therefore, you need to have the Power Tools installed for Team Foundation Server.

From the command-line you can execute the tfpt unshelve command with the name of the shelveset to accomplish that.

tfpt unshelve allows a shelveset to be unshelved into a workspace with pending changes. Merges content between local and shelved changes. Allows migration of shelved changes from one branch into another by rewriting server paths.

Like in a normal get latest scenario, you will be asked to resolve conflicts and eventually be redirected to the well known TFS merge window.

 
If you hold on to a specific Team Build retention policy (new since TFS2008), you might lose all valuable build information of a particular build that you actually wanted to keep.

There’s an option available via the Build Explorer to retain builds indefinitely!

 
By default, Team Explorer always tries to automatically connect at startup to the latest known Team Foundation Server. In my case I often start Visual Studio Team System at home when I was previously connected to the Team Foundation Server at work. So, when disconnected from work, I always get the TF30331 error …

Today, this error hit me for the last time! On the Developer Support Team Foundation Server blog I found how to disable the auto-connection! Sweet!

To make this happen, add a DWORD value called “AutoLoadServer” under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation (for 2005 – change this to 9.0 for Orcas). A setting of Zero means do not reconnect automatically.

 
DYK = Did You Know?

Internet Information Server (IIS) is not required to be installed for a TFS 2008 Team Build machine

The application server for TFS 2005 still used .NET Remoting to communicate with the Team Build machine, but as from TFS 2008 the communication is set up with Windows Communication Foundation. The WCF service runs in a managed Windows Service (TfsBuildService.exe).

 
In the current available versions of Team Foundation Server [TFS2005 and TFS2008] it’s hard to look up changes that originated in another branch. Let me explain this by an example.

I have a Main branch and two feature branches that were both branched from Main. Now let’s assume certain changes are made to FeatureBranch1. These changes are merged (reverse integration) to Main and at a later stage a release branch (1.1) is split off to the Release folder (from Main). Some time later the code file is being inspected in the 1.1 branch (release folder) where the code change of FeatureBranch1 was executed. In the Annotate window [a new feature in TFS2008] you would be able to see that on line x a change was made by person y on time z. So far so good! The question that now pops up is : “What do you really want to see in the changeset details?”. The best answer of course is that you immediately want to see that those changes originated from the FeatureBranch1, but at this moment TFS2008 won’t provide you with this information. You will have to manually drill down the branch hierarchy to find out that this change came from a check-in into the FeatureBranch1 by person x. TFS 2008 only gives you the information (via the annotate feature) that the change came from a merge (Main branch). This is not ideal, because you will have to step into the history and dig deeper to find out the original changeset in FeatureBranch1.

TFS 2010 will come to the rescue in the future and will provide you with the details you are really looking for in that type of situation. In the tooltip of changeset 74, TFS drills down through all merges and loads the details of the initial check-in at FeatureBranch1. Note that the screenshot is taken in the source of code in the 1.1 release branch.

Right-clicking on the changeset 74 hyperlink will even give you the option to view the original changeset details of the FeatureBranch1 check-in or to view the history …

The history window as seen above will now give you a hierarchical view on how the changeset came into the release 1.1 branch. To top it off, you can also track the 74 changeset visually by right-clicking …

The first view in the screenshots below is a timeline view where you can follow the merge history of changeset 74 and the second view is a hierachical view where you can detect the hierarchical dependencies between branches.

Very nice features I wish I had already at my disposal right now …

 
This is not yet a widely known practice in the field, but setting up a Source Server for TFS Builds in an enterprise development environment can be extremely valuable.

My friend and ex-colleague Jelle Druyts wrote a few months ago an excellent blog post about how to set up a Source Server for TFS Builds.

Anyone who will reference assemblies that are built with a source server enabled TFS Build will be able to debug those assemblies in the original source code … great for framework code for instance!

When an assembly is “source server-enabled”, the pdb file will contain the full path and the exact version of the file in source control that was used to build that assembly. If the debugger then enters a method, Visual Studio automatically downloads that correct file, places it in a local cache, and opens it for debugging. This is super sweet!

If you follow the guidelines of Jelle, you need to add the custom target RunSourceServerIndexing somewhere in your Team Build script, but he doesn’t specify exactly where you need to include this.

Well, you have two options : you can do this in your TFSBuild.proj file or you can also put this custom target in an underlying .targets file to make it more reusable. The TFSBuild.proj file is the easiest option, but I would recommend an underlying .targets file. In fact it’s always a good practice to make an underlying .targets file for all your common Team Builds. The idea is to make your .proj file as clean as possible and put all the logic and commands in an underlying .targets file.

In the image above you can see that I’ve created a specific target for all Compuware Team Builds on the Build Server. This .targets file must be imported in all TFSBuild.proj files and to enable source server for my Team Builds, I’ll just need to create a boolean variable in my TFSBuild.proj and pass it to the Compuware.targets file.

The Compuware.targets file will do all the required steps in the background. Note that the default is set to false for the variable SourceServerIndexing.

If you follow this pattern for other build tasks, you will end up with a clean TFSBuild.proj file and you will only need to pass booleans (and/or other variables) to the underlying .targets file that will contain all the reusable build tasks. Note that automatically all TFSBuild.proj files will import the default Microsoft.TeamFoundation.Build.targets file. Make sure that you never edit this master file, because it may jeopardize the working of your Team Builds when you need to migrate to another version of MSBuild.

Another small issue I came across when following the guidelines : the location where to drop the TFIndex.cmd file may be different than pointed out in the document (due to a different default location of the Debugging Tools). If that’s the case you must also check the location of this file when you set the custom target RunSourceServerIndexing.

If you haven’t taken the time to explore the possibilites of a Source Server for your TFS Builds, please do so now! You won’t regret!

 
From Wikipedia …

A fully qualified domain name (or FQDN) is an unambiguous domain name that specifies the exact location in the Domain Name System’s tree hierarchy through to a top-level domain and finally to the root domain. Technically, a FQDN has a trailing dot (for example: somehost.example.com.), but most DNS resolvers will treat any domain name that already has a dot as being an FQDN and add the final dot needed for the root of the DNS tree.

A lot of companies will use FQDN what means that Team Foundation Server won’t work with the default installation procedure. At first sight, you might think it works, but for Windows SharePoint Services and Reporting Services it won’t! There’s a pretty good blogpost from Buck Hodges available that guides you how to modify the default TFS configuration. Here’s what I did to get TFS working with FQDN :

• Run tfsadminutil activateat MyFQDN. This command (tfsadminutil can be found in the Tools folder of the TFS installation folder) will activate the FQDN computer as the TFS application-tier server. One of the executed tasks is the modification of the global TFS web.config (config file can be found in the Web Services folder of the TFS installation folder). You may verify the TFSNameUrl setting in the configuration file. I also manually added the appsetting TfsUrlPublic with as value the http://*FQDN*:8080 to force FQDN references in e-mail notifications. Another task the command does is changing the TFS service interface. You may verify this in the tbl_service_interface table of the TfsIntegration database. All urls should now match the FQDN. Before all urls contained the netbiosname of the computer.
• Update registry settings BaseReportsUrl and ReportsService with my FQDN at HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\ReportServer\80\Sites.
• For WSS 3.0 to work with TFS 2008, I still had to add an alternate access mapping (see blogpost Buck Hodges how to cope with that).

 
When creating a new Team Build with the Build Wizard in TFS 2008, it may be possible that you won’t have code coverage results while you have this option enabled in your testrun configuration file. This depends on how you selected your tests to run …

1. If you have chosen to run tests that are listed in a Test List, then there won’t be any problem : code coverage results will be available because all testrun configuration settings will be picked up in the testrun configuration file via the .vsmdi file.
2. If you have chosen to run tests with the TestContainer option, then the testrun configuration file is not picked up because there won’t be any trace of a .vsmdi file in your build project file. You may fix this by manually adding the following line to your .proj file.

   <RunConfigFile>$(SolutionRoot)\$filename$.testrunconfig</RunConfigFile>

   This line (to be added in PropertyGroup of .proj file) will pick up the test run configuration file and will control the way tests are run.

While VS 2008 SP1 and SQL Server 2008 were relatively painless to install, I run into some issues with the TFS 2008 SP1.

I’ll tell briefly my case so you can avoid this or find the solution, should you have the same reason for the problem.

The TFS 2008 is installed on a single Windows Server 2008 machine (except SharePoint) and uses SQL Server 2005 SP2.

When I tried to install the KB949786 (TFS SP1), the first part went always fine (TFS Build), but it ended in Fatal Error during the update of the actual TFS. TFS got into unusable state (clients couldn’t connect etc)

The errors in the Event Log were:

“Product: Microsoft Visual Studio 2008 Team Foundation Server – ENU – Update ‘KB949786′ could not be installed. Error code 1603. Additional information is available in the log file <file>”

and

“Product: Microsoft Visual Studio 2008 Team Foundation Server – ENU — Error 29003.TF 230001: The error mode for the Team Foundation Server Web application could not be configured properly. This problem occurred because the application root for the Team Foundation Server Web application does not exist. For more information, see the Microsoft Windows Installer (MSI) log.”

After some googling, I found similar symptoms from the MSDN Forums. Logins etc were alright in my case, so the reason was elsewhere. (Tip: don’t change TFS service accounts unless you have a very good reason and if you do, use the tools mentioned in the forum)

Finally I just had to go through the installation log and from there I found the reason:

08/13/08 10:51:15 DDSet_Status: Commandline: "C:\Windows\system32\inetsrv\appcmd.exe" set config "Team Foundation Server" -section:httpErrors -existingResponse:PassThrough -commitpath:apphost
08/13/08 10:51:15 DDSet_Status: IgnoreExitCode: 0
08/13/08 10:51:15 DDSet_Status: Silent: 0
08/13/08 10:51:15 DDSet_Status: ActionStart: 0
08/13/08 10:51:15 DDSet_Status: Cost: 0
08/13/08 10:51:15 DDSet_Status: WorkingDirectory:
08/13/08 10:51:15 DDSet_Status: HideCmdLine: 0
ERROR ( message:Cannot find SITE object with identifier "Team Foundation Server". )
08/13/08 10:51:16 DDSet_Status: Process returned 1168
08/13/08 10:51:16 DDSet_Status: Found the matching error code  for return value ‘1168′ and it is: ‘29003′
08/13/08 10:51:16 DDSet_Error:  1168
MSI (s) (B8!94) [10:51:16:127]: Product: Microsoft Visual Studio 2008 Team Foundation Server – ENU — Error 29003.TF 230001: The error mode for the Team Foundation Server Web application could not be configured properly. This problem occurred because the application root for the Team Foundation Server Web application does not exist. For more information, see the Microsoft Windows Installer (MSI) log.

I have the habit of putting server port in the names of the web sites in the IIS and I had renamed the “Team Foundation Server” to “Team Foundation Server – 8080”. The patch was obviously looking for the original name and failed because it didn’t find a web site with exactly the same name.

I just renamed the web site hosting the web services back to “Team Foundation Server”, run the patch again (without uninstalling it first) and everything went fine.

Microsoft, you could modify that part of the patch to search the web site with partial match or better: with some kind of unique ID of the web site instead of the name.

TFS is still very new product and it relies on so many other services and products that there are many places where something can go wrong. This is why it is better not to mess with anything directly without using official tools.

This weekend I finally pulled the trigger on upgrading our TFS environment from TFS 2005 to 2008. By and large this was a pretty painless upgrade with the notable exception of TFS Build which has turned out to be a royal pain.

Don’t get me wrong, feature-wise TFS Build 2008 is far superior to the 2005 version, but it was pretty discouraging to find that the build types created for a set of Visual C++ 2005 solutions just completely stopped working. I eventually gave up on the existing build types and started over with a fresh build type and by numerous searches, I’ve been able to get most things working.

Building VS 2005 Solutions

For various reasons, we have one project that we can’t upgrade to Visual Studio 2008 quite yet, so I had to keep the solution files as VS 2005 solution files, but still be able to build them with TFS Build 2008. After poking around a bit, these blog posts told me how to configure that:

• Overriding the ToolsVersion for Your Projects in Team Build
• Building VC++ 2005 Projects With Team Build 2008

In my TFSBuild.proj, I specified the solutions to build as:

<SolutionToBuild Include="<solution path>">
    <Targets></Targets>
    <Properties>ProjectToolsVersion=2.0;VCBuildToolPath=$(ProgramFiles)\Microsoft Visual Studio 8\vc\vcpackages</Properties>
</SolutionToBuild>

The property ProjectToolsVersion tells TFS Build to target .NET 2.0 and the VCBuildToolPath tells it to use the specified path to find VCBuild.exe which is used to build Visual C++ projects.

Generating Custom Build Numbers

We already had functionality to automatically update the product and file versions of our binaries as part of the build so that every build generated binaries with a unique version number. TFS Build 2008, however, offers the possibility to customize the build number. I thought it would be useful to let the build number match the file version generated by the build, making it easier to identify a particular build just by looking at the version number.

Again, there were several blog posts that talked about how to generate custom build numbers:

• Aligning Build Numbers with Assembly Versions in TFS2008
• Orcas SP1 TFS Build Changes, Part 2

I wound up using a slightly different approach than the above. I’m still using a file containing the version number of the previous build (e.g. 1.2.3.4), but I wanted my file to be version controlled which posed a problem since the build number must be generated at the very beginning of the build, before all the source files to use for the build have been retrieved.

Since all I had available to me were the files that are located in my build type directory, I simply moved my version file to the build type directory which ensures it’s available to me. Next, I used the Version task from the MSBuild Community Tasks project to update this file:

<Target Name="BuildNumberOverrideTarget">

<!– Update the product version number –>

<Version VersionFile="$(TxProductVersionFile)" BuildType="None" RevisionType="Increment">
  <Output TaskParameter="Major" PropertyName="TxMajorVersion" />
  <Output TaskParameter="Minor" PropertyName="TxMinorVersion" />
  <Output TaskParameter="Build" PropertyName="TxPatchVersion" />
  <Output TaskParameter="Revision" PropertyName="TxBuildVersion" />
</Version>

<CreateProperty Value="$(TxMajorVersion).$(TxMinorVersion).$(TxPatchVersion).$(TxBuildVersion)">
  <Output TaskParameter="Value" PropertyName="TxCompleteVersion"/>
</CreateProperty>

<CreateProperty Value="$(TxMajorVersion),$(TxMinorVersion),$(TxPatchVersion),$(TxBuildVersion)">
  <Output TaskParameter="Value" PropertyName="TxCompleteVersionRc"/>
</CreateProperty>

<!– Define the build version number –>
<PropertyGroup>
  <BuildNumber>$(TeamProject)_$(BuildDefinitionName)_$(TxCompleteVersion)</BuildNumber>
</PropertyGroup>

</Target>

This gives me my custom build number, but I also need to check the changed version number file back in. The easiest way to do this was to override the AfterGet target:

<Target Name="AfterGet">
   <Message Text="Updating the version-controlled product version file"/>
   <CallTarget Targets="UpdateVersionedProductVersionFile"/>
  <Message Text="Updating the product version information in preparation for the build." />
  <CallTarget Targets="SetProductVersionForBuild" />
</Target>

Where the definition of UpdateVersionedProductVersionFile is:

<PropertyGroup>
  <UpdateVersionedProductVersionFileDependsOn>
  </UpdateVersionedProductVersionFileDependsOn>
</PropertyGroup>
<Target Name="UpdateVersionedProductVersionFile" DependsOnTargets="$(UpdateVersionedProductVersionFileDependsOn)">
  <!– Check out the product version file we now have available to us after the source files have been retrieved. –>
  <Exec WorkingDirectory="$(SolutionRoot)" Command="$(TxTf) checkout &quot;$(TxVersionedProductVersionFile)&quot;"/>

  <!– Copy the previously updated product version file to the version-controlled product version file –>
  <Copy SourceFiles="$(TxProductVersionFile)" DestinationFiles="$(TxVersionedProductVersionFile)"/>

  <!– And finally check the file back in so it’s available for the next build. –>
  <Exec WorkingDirectory="$(SolutionRoot)" Command="$(TxTf) checkin /override:&quot;Automated build check-in, no associated work items&quot; /comment:&quot;Checking in the updated product version file for build $(BuildNumber)&quot; &quot;$(TxVersionedProductVersionFile)&quot;"/>
</Target>

TxProductVersionFile defines the fully qualified path of the version number file in the BuildType directory created by TFS Build when the build is initiated and TxVersionedProductVersionFile the fully qualified path of the same file in the Sources directory (which of course means that I have configured my build type so that the build type itself is included in the workspace, this is easy to do in the new build type editor).

More Stuff

The above is what I’ve come up with so far. I still have to figure out why my code signing is failing (this is my fault, I changed the user account used to run TFS build, so I have to move the certificate to the appropriate certificate store) and my unit tests don’t appear to run properly yet.

I’ll post an update once I get that sorted out.

Update

I did manage to get the code signing sorted out. It turns out I was trying to import the code-signing certificate in a .spc format which isn’t good enough for code-signing purposes. The certificate needed to be in .pfx format to be imported and used properly for code-signing (the certificate would still show up in the Certificates MMC console, but SignFile task would fail with the error message that no certificate was found that matched all criteria).

Another item I found is that there now are several new targets you can override for the build, see Customizable Team Foundation Build Targets for more information. For our needs, the AfterCompileConfiguration target comes in handy since that lets us conveniently create a single build that builds the code, signs the binaries, builds the installer and then finally sings the installer.

That said, I still haven’t figured out why my unit tests won’t run…

Another Update

After having upgraded our solution to VS2008, the unit tests are now running just fine on our build server. I didn’t spend a whole lot of time researching the issue while the solution was still using VS2005 as moving it to VS2008 was one of our short term goals anyway.

Here are the definitions of the TxProductVersionFile and TxVersionedProductFile properties.

<!–

More Build Definitions

In response to Stephen’s questions:

1. $(TxTf) is defined as:

    <!-- The fully qualified path of tf.exe, used to check in/out items during the build -->
    <TxTf>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TxTf>

Basically it defines the fully qualified path of tf.exe which I use to run TFS-related commands that don’t have a convenient existing MSBuild target (keep in mind that I did fairly minimal work on this build script as part of the update, there may have been new targets added that I just haven’t looked for yet in TFS 2008).

2. That was a typo I introduced when copying the code from the .targets file to WordPress, the extra quotes have to be XML encoded, I’ve updated that code above.

3. The definitions of SetProductVersionForBuild target (and dependent targets) are:

  <!--
    SetProductVersionForBuild increments the version number in the global version number
    file and updates the product version information in all .rc files accordingly.
  -->
  <PropertyGroup>
    <SetProductVersionForBuildDependsOn>
      IncrementRcProductVersions;
      IncrementRcFileVersions;
    </SetProductVersionForBuildDependsOn>
  </PropertyGroup>
  <Target Name="SetProductVersionForBuild" DependsOnTargets="$(SetProductVersionForBuildDependsOn)">
    <Message Text="Updated the version information in preparation for the build."/>
  </Target>

  <!--
    IncrementRcProductVersions updates the ProductVersion information in all
    .rc files in the project.
  -->
  <PropertyGroup>
    <IncrementRcProductVersionsDependsOn>
      CheckOutRcFiles;
    </IncrementRcProductVersionsDependsOn>
  </PropertyGroup>
  <Target Name="IncrementRcProductVersions" DependsOnTargets="$(IncrementRcProductVersionsDependsOn)">
    <FileUpdate Files="@(TxRcFiles)" Encoding="ASCII" Regex="PRODUCTVERSION\s+\d+\s*,\s*\d+\s*,\s*\d+\s*,\s*\d+" ReplacementText="PRODUCTVERSION $(TxMajorVersion),$(TxMinorVersion),$(TxPatchVersion),$(TxBuildVersion)"/>
    <FileUpdate Files="@(TxRcFiles)" Encoding="ASCII" Regex="VALUE\s+&quot;ProductVersion&quot;\s*,\s*&quot;\d+\s*[\.,]\s*\d+\s*[\.,]\s*\d+\s*[\.,]\s*\d+\s*(\)*&quot;" ReplacementText="VALUE &quot;ProductVersion&quot;, &quot;$(TxMajorVersion).$(TxMinorVersion).$(TxPatchVersion).$(TxBuildVersion)&quot;"/>
  </Target>

  <!--
    IncrementRcFileVersions updates the ProductVersion information in all
    .rc files in the project.
  -->
  <PropertyGroup>
    <IncrementRcFileVersionsDependsOn>
      CheckOutRcFiles;
    </IncrementRcFileVersionsDependsOn>
  </PropertyGroup>
  <Target Name="IncrementRcFileVersions" DependsOnTargets="$(IncrementRcFileVersionsDependsOn)">
    <FileUpdate Files="@(TxRcFiles)" Encoding="ASCII" Regex="FILEVERSION\s+\d+\s*,\s*\d+\s*,\s*\d+\s*,\s*\d+" ReplacementText="FILEVERSION $(TxMajorVersion),$(TxMinorVersion),$(TxPatchVersion),$(TxBuildVersion)"/>
    <FileUpdate Files="@(TxRcFiles)" Encoding="ASCII" Regex="VALUE\s+&quot;FileVersion&quot;\s*,\s*&quot;\d+\s*[\.,]\s*\d+\s*[\.,]\s*\d+\s*[\.,]\s*\d+\s*(\)*&quot;" ReplacementText="VALUE &quot;FileVersion&quot;, &quot;$(TxMajorVersion).$(TxMinorVersion).$(TxPatchVersion).$(TxBuildVersion)&quot;"/>
  </Target>

  <!--
    CheckOutRcFiles checks out all .rc files in the Source directory in preparation
    for them to be updated with new version information.
  -->
  <PropertyGroup>
    <CheckOutRcFilesDependsOn>
      FindAllRcFiles;
    </CheckOutRcFilesDependsOn>
  </PropertyGroup>
  <Target Name="CheckOutRcFiles" DependsOnTargets="$(CheckOutRcFilesDependsOn)">
    <!-- Note that this command is run in our Source directory so we don't check out files from the Extern directory -->
    <Exec WorkingDirectory="$(TxSourceDir)" Command="$(TxTf) checkout /recursive $(TxRcSpec)"/>
  </Target>

  <!--
    CheckOutRcFiles checks in all .rc files in the Source directory that were
    updated with the new version information.
  -->
  <PropertyGroup>
    <CheckInRcFilesDependsOn>
    </CheckInRcFilesDependsOn>
  </PropertyGroup>
  <Target Name="CheckInRcFiles" DependsOnTargets="$(CheckInRcFilesDependsOn)">
    <!-- Note that this command is run in our Source directory so we don't check out files from the Extern directory -->
    <Exec WorkingDirectory="$(TxSourceDir)" Command="$(TxTf) checkin /override:&quot;Automated build check-in, no associated work items&quot; /comment:&quot;Checking in the updated resource files for build $(BuildNumber)&quot; /recursive $(TxRcSpec)"/>
  </Target>

  <!--
    The FindAllRcFiles target finds all .rc files under $(SolutionRoot) and
    stores that information in the $(TxRcFiles) property.
  -->
  <PropertyGroup>
    <FindAllRcFilesDependsOn>
    </FindAllRcFilesDependsOn>
  </PropertyGroup>
  <Target Name="FindAllRcFiles" DependsOnTargets="$(FindAllRcFilesDependsOn)">
    <CreateItem Include="$(TxSourceDir)\**\$(TxRcSpec)">
      <Output ItemName="TxRcFiles" TaskParameter="Include"/>
    </CreateItem>
  </Target>