Question

Setting up a new team build in tfs build 2008, you re forced to select a .sln file for your build definition.

I ve read through Microsoft.TeamFoundation.Build.Targets, and from what I understand, all team build does is convert the silly .sln format to msbuild in tfsbuild.proj on-the-fly, and then build that. So what you end up with is tfsbuild.proj calls mysolution.sln which then calls myproject.csproj.

What I would prefer would be to have tfsproj import myproject.csproj, override a few targets, and skip the whole .sln=>msbuild black box.

Has anyone done this? what are the right targets to override to cleanly amputate the .sln mess? I m thinking CoreCompileConfiguration will need to be overridden.

What would I be losing by cutting out the .sln functionality?

Answer 1

TFS 2008 can build solutions or projects. You just need to specify the project (e.g. .csproj) files to build in the SolutionsToBuild property and make sure the configurations and platforms to build match up with your project(s).

There s a discussion of the ins and outs here: How to build a .csproj using TFS 2008 and MSBuild

Answer 2

Here is something we use in out project. It is not perfect, but does the trick.

<Target Name="CoreCompile"
    DependsOnTargets="$(_CoreCompileDependsOn)"
    Outputs="@(CompilationOutputs)">

  <MakeDir Directories="$(BinariesRoot)" Condition="!Exists( $(BinariesRoot) )" />

  <MSBuild Projects="$(SolutionRoot)$(SrcBranch)WholeProject.proj"
             StopOnFirstFailure="$(StopOnFirstFailure)">
    <Output TaskParameter="TargetOutputs" ItemName="CompilationOutputs" />
  </MSBuild>
</Target>

the WholeProject.proj is the file used on developer machine builds and on the build machine.

I m not sure now why the CoreCompile must be overridden, most probably because the original one always looks for some property and expects it exists and contains valid .sln file

友情链接