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 Micros开发者_如何学JAVAoft.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?
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
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
精彩评论