Team Build and ClickOnce

The other day I got a question: How can I deploy an app via ClickOnce using Team Build?

There is not out of box way to do that, but we can do it with a simple workaround:

we should overload the target AfterCompile in TFSBuild.Proj to call MSBuild Task Publish and can pass the PublishDir property:

<Target Name="AfterCompile">
  <MSBuild
  Condition=" '@(SolutionToBuild)'!='' "
  Projects="@(SolutionToBuild)"
  Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);
    Platform=%(ConfigurationToBuild.PlatformToBuild);
    SkipInvalidConfigurations=true;
    VCBuildOverride=$(MSBuildProjectDirectory)\TFSBuild.vsprops;
    FxCopDir=$(FxCopDir);OutDir=$(OutDir);
    PublishDir=$(OutDir);
    ReferencePath=$(ReferencePath);
    TeamBuildConstants=$(TeamBuildConstants);
    $(CodeAnalysisOption);PublishDir=\\qa1Srv\drops\publishedVers\ "
  Targets="Publish" />
</Target>

From: http://vstskb.net/blog/2008/09/team-build-and-clickonce/

Configure Team Foundation Build for an Incremental Build

A question I got today: "How can I configure my Team Build for an incremental build?".

So, it's simple.

Team Build 2005

Add the PropertyGroup definition to the end of the TFSBuild.proj file, before the closing </project> tag.

Set the following properties:

   <PropertyGroup>
      <SkipClean>true</SkipClean>
      <SkipInitializeWorkspace>true</SkipInitializeWorkspace>
      <ForceGet>false</ForceGet>
   </PropertyGroup>

 

Team Build 2008

Set IncrementalBuild property to true. To do it, add the PropertyGroup definition to the end of the TFSBuild.proj file, before the closing </project> tag.

   <PropertyGroup>
      <IncrementalBuild>true</IncrementalBuild>
   </PropertyGroup>

 

Source - msdn:

Team Build 2005: http://msdn.microsoft.com/en-us/library/aa833876(VS.80).aspx

Team Build 2008: http://msdn.microsoft.com/en-us/library/aa833876.aspx

How To Deploy Data Dude Project Changes using Team Foundation Build

When you want to build and deploy database projects with team build you need to edit the database project file and the Team Build file. That's because database projects store any non-default values for the TargetDatabase, TargetConnectionString, and DefaultDataPath properties in a <ProjectName>.dbproj.user file.  *.user files are not checked into version control in order to let every user use different values.

 

Step 1 - Modify build project file (team build .proj file)

Open the BuildDefinition.proj file, and at the bottom of the file, between the </ItemGroup> element and the </Project> element, add the following:

<Target Name="AfterDropBuild">
  <MSBuild Projects="$(SolutionRoot)\SolutionName\ProjectName\ProjectName.dbproj" 
      Properties="Configuration=Default;OutDir=$(SolutionRoot)\..\binaries\Default\" Targets="Deploy" />
</Target>

 

Step 2 - modify the database project file

The target connection and database are stored in the ProjectName.dbproj.user file, which is user specific and not typically checked in to version control. You require those settings to deploy your database. Therefore, you must modify the ProjectName.dbproj file manually to specify the target connection and database.

Copy the lines that contain the definitions for the TargetDatabase and TargetConnectionString properties from the section in the ProjectName.dbproj.user file for the configuration that you want to build. These lines will resemble the following:

<TargetDatabase>MyTargetDatabaseName</TargetDatabase>
<TargetConnectionString>Data Source=ServerName\InstanceName;Integrated Security=True;Pooling=False</TargetConnectionString>

If TargetDatabase and TargetConnectionString already contain empty elements, you should overwrite those entries.

 

More into at the msdn page.

Remove Items From ItemGroups In MSBuild

The ability to remove entries from ItemGroups is one of the new features of MSBuild 3.5.

To remove an Item from an ItemGroup in MSBuild 2.0 you would have to create a new ItemGroup from the old one and skip the Item that you needed removed.

In MSBuild 3.5 we can achieve it by using the Remove parameter.

Example:

<ItemGroup>
    <Files Include="a.cs" />
    <Files Include="b.cs" />
    <Files Include="c.cs" />
    <Files Include="d.cs" />
    <Files Include="e.cs" />
    <Files Include="f.cs" />
    <Files Include="g.cs" />
</ItemGroup>

Some times we want to restrict some data from this group in a target. In order to do it,  we should use the Remove parameter:

<ItemGroup>
    <Files Remove="a.cs" />
    <Files Remove="e.cs" />
    <Files Remove="f.cs" />
</ItemGroup>

Read more at msdn.

Running Tests On TFS Build Machine

Often I asked "What do I need to install on the TFS build machine in order to run tests?"

Well, the answer is simple.

In VSTS 2005 you have to install the Tester or Suite editions on the Build Machine to run tests (even Unit Tests).

In VSTS 2008 installing the Developer Edition version is enough.

Building VS 2008 projects with TFS 2005

When you try to build VS 2008 solutions with Team Foundation Build 2005 you get:

MSB5014 - File format version is not recognized.

I posted about it and one of the comments (by Eran Kampf) linked to Mitch Denny's approach. Customers ask me about it a lot and this is the best approach to deal with the problem.

Buck Hodges says that the best "workaround" is to upgrade to TFS 2008. But not all of you will upgrade soon to 2008. For you, Mitch's approach is the best.

Technorati Tags: Team Build,Team Build 2008

Team Foundation Build 2008 New Features Video

There's a great new video on MSDN by Richard Hundhausen introducing the new features in Team Foundation Build 2008: How Do I: Learn the New Features and Capabilities of Team Foundation Build 2008?

The video covers the major new features and provides a great introduction to the product.

Technorati Tags: TeamBuild,TFS 2008,Team Build 2008

TFS Build Lab 1.0 Released

TFSBuildLab 1.0 is released on CodePlex.  

This is a project to simplify the day to day operations when using automated builds on TFS.

This project handles common Team System issues such as:

• Continuous integration builds
• Scheduled builds
• Build queuing
• Event notifications
• Manual and automated build cleanup

What features included in V1.0:

Service

• Automatic rescheduling when adding new scheduled trigger.
• A report for displaying statistics from the triggers and retention policies.
• Support for overriding build script parameters both for CI and queued builds.
• Support for only deleting the build drops.
• Support for configuring retention policies based on build quality.
• Performance improvements by introducing caching

Admin Client

• Added feedback when deleting multiple builds.
• Support for forcing reaching on the server.
• Support for overriding build script parameters on queued builds.
• Support for overriding build script parameters on triggers.
• Added range parameters when listing log entries to limit the result data.

Checkin Policies

• Removed the need for TfsBuildLab when using the restricted paths policy.

Technorati Tags: Team Build, Team System, MSBuild

Build a labeled version with TeamBuild

This is the 3rd post in the series of posts about MSBuild. You can read them at:

1. Introduction to MSBuild.
2. Create custom task to MSBuild - step by step.

As you know, TeamBuild builds the latest version by default. At the Target "CoreGet" in the MSBuild script (you can find it at Microsoft.TeamFoundation.Build.targets file), it gets the latest version from source control to the local workspace on the build machine and build the source.

To build a labeled source you have to set a value to the Version property of the Get task in this target.

So, all you need to do is to override the CoreGet target in the TfsBuild.proj file (it's better than override it in the target file because if you do so, this change will affect all builds on the machine...):

   1:  <Target Name="CoreGet"

   2:        Condition=" '$(IsDesktopBuild)'!='true' "

   3:        DependsOnTargets="$(CoreGetDependsOn)" >

   4:   

   5:      <!-- Get all the latest sources from the given workspace-->

   6:      <Get Condition=" '$(SkipGet)'!='true' "

   7:          Workspace="$(WorkspaceName)"

   8:          Recursive="$(RecursiveGet)"

   9:          Force="$(ForceGet)"

  10:          Version="$(VersionToBuild)" />      

  11:  </Target>

The property in line 10 is the property that do the work...

You can declare the $VersionToBuild variable at the PropertyGroup element or by passing this value from the .rsp file. The easiest way is to declare it at the PropertyGroup element.

   1:  <PropertyGroup>

   2:      <VersionToBuild>M_1.0.0.223</VersionToBuild>

   3:  </PropertyGroup>

That's all!

Enjoy.

Technorati Tags: MSBuild, TeamBuild

Building .NET 3.0 projects from Team Foundation Build 2005 not supported

Building .NET 3.0/3.5 projects from Team Foundation Build 2005 not supported. Team Foundation Build 2005 will always invoke the 2.0 Framework's MSBuild.exe, which does not support building solutions that target the 3.5 Framework.  (The 3.0 Framework shipped with Vista, while the 3.5 Framework is shipping with VS 2008.)

The 3.5 Framework includes new MSBuild bits which allow multi-targeting - i.e. MSBuild 3.5 can target the 2.0 Framework.

We can convert our solution to VS2008 beta 2 and target the solution to .NET framework 2.0. It's not enough. When we'll try to build this solution with Team Foundation Build 2005, we'll get an error MSB5014 - File format version is not recognized.

The MSBuild blog has great post about MSBuild, Orcas, and Multi-targeting. Find it here.