Grant Holliday

The Visual Studio 2008 (Orcas) version of MSBuild supports “Multi-targeting”. ScottGu’s blog post and the MSBuild Team blog sum it up nicely:

One of the big changes we are making starting with the VS 2008 release is to support what we call “Multi-Targeting” - which means that Visual Studio will now support targeting multiple versions of the .NET Framework, and developers will be able to start taking advantage of the new features Visual Studio provides without having to always upgrade their existing projects and deployed applications to use a new version of the .NET Framework library.

This is great news. It means that you can start using Team Build 2008 and/or Visual Studio 2008 to build existing solutions that target the .NET 2.0 runtime. This gives you the flexibility to upgrade to .NET 3.5 when your development cycle allows. (As a side note, if you want to build .NET 3.5 applications with Team Build 2005, this should help)

But what if you work in an organisation that has standardised on .NET 2.0 for the production end-user’s environment? In this scenario you probably don’t want anybody building assemblies that target the .NET 3.5 runtime. Or maybe you are living on the edge and you want to ONLY build assemblies that target the .NET 3.5 runtime, etc.

Well here’s a no-custom-code solution - all done with a snippet for your TFSBuild.proj file.

• The build will fail if any of the projects within the build don’t match the <AllowedTargetFrameworkVersion> that has been set.
• You will need at least the v1.2.0.306 MSBuild Community Tasks installed/available.
• Currently it matches all *.csproj files recursively, regardless of whether they are in the build configuration or not.
• If you want to actually enforce this, make sure that developers can’t change the file. It might be useful to store it on the server and use an <Include>.

<!-- TFS Build 2008.
     This snippet checks the <TargetFrameworkVersion> of a Visual Studio 2008 project file.
     It fails the build if the version does not match the allowed version.

     This should be used when you want to use VS2008, but ensure that your binaries remain as .NET 2.0
-->

  <PropertyGroup>
    <!-- The TargetFrameworkVersion that you want to match. e.g. v2.0, v3.0 or v3.5 -->
    <AllowedTargetFrameworkVersion>v2.0</AllowedTargetFrameworkVersion>
  </PropertyGroup>
  

  <!-- Override the Team Build AfterGet target, before any compilation starts -->
  <Target Name="AfterGet" >
    <CallTarget Targets="CheckTargetFrameworkVersions" />
  </Target>

  <UsingTask AssemblyFile="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll" TaskName="MSBuild.Community.Tasks.Xml.XmlQuery" />

  <!-- Only run if the AllowedTragetFrameworkVersion property is set -->
  <Target Name="CheckTargetFrameworkVersions" Condition=" '$(AllowedTargetFrameworkVersion)' != '' ">
    <Message Text="Allowed Target Framework Version is: $(AllowedTargetFrameworkVersion)" Importance="high" />

    <!-- Get all *.csproj files in the working directory.
    Ideally this should look at the current build configuration
    and return the filenames of the projects to be built.
    But as Team Build passes SolutionToBuild to MSBuild, we can't get
    the list of projects easily.
    -->
    <CreateItem Include="$(SolutionRoot)\**\*.csproj">
      <Output TaskParameter="Include" ItemName="ProjectFiles" />
    </CreateItem>

    <!-- Extract the TargetFrameworkVersion element from each of the project files -->
    <Xml.XmlQuery
      NamespaceDefinitions="n=http://schemas.microsoft.com/developer/msbuild/2003"
      XmlFileName="%(ProjectFiles.FullPath)"
      XPath="/n:Project/n:PropertyGroup/n:TargetFrameworkVersion">
      <Output TaskParameter="Values" ItemName="TargetFrameworkVersions" />
    </Xml.XmlQuery>

    <Message Text="Found Target Framework Version: %(TargetFrameworkVersions._value)" Importance="low" />

    <!-- Throw an error if any of the target versions don't match -->
    <Error Condition="'%(TargetFrameworkVersions._value)' != '$(AllowedTargetFrameworkVersion)'"
           Text="Target Framework Version is not allowed: %(TargetFrameworkVersions._value). Allowed version: $(AllowedTargetFrameworkVersion)" />

  </Target>

This makes use of the excellent <Xml.XmlQuery> task that uses ITaskItem parameters. By using ITaskItem as the parameter type instead of say, string - this allows us to pass an array of values and the task gets performed for each item in the array.

As I mentioned in my last post, I’m presenting at Security Camp Oz this year.

Here is the slide deck PPTX for those that are interested:

• Securing your Team Foundation Server development environment (~851kb)

TFSBUILD

One of the nuggets in the presentation is “Don’t run the Team Build server under the TFSSERVICE account” (as the install docco incorrectly states - it will be fixed soon).

The reason is that TFSSERVICE is a member of “[SERVER]\Service Accounts”, which is a member of the “[SERVER]\Team Foundation Server Administrators” global group.

So what you have here, is a service running as a privileged account within TFS that executes build scripts. If you look inside the slide deck you can see how easy it is to exploit this.

Fortunately it’s easy to protect against this kind of attack - don’t run Team Build as TFSSERVICE - run it as another account called TFSBUILD, and don’t make this account a TFS administrator.