TFS & Visual Studio ALM – by Neno Loje

(formerly Team System, VSTS)

[Team Build] Why is the "DropBuild" target *after* the "AfterDropBuild" target?

January 31st, 2007 · No Comments · Team Foundation Build (TF Build)

People tend to ask me why the order for the build-in Team Build targets usually is:

  • BeforeSomething
  • CoreSomething
  • AfterSomething
  • Something

    (Replace “Something” with a action like “Get”, “Compile”, “DropBuild”, or similar …)

You can find the execution order of the Team Build Targets published in the MSDN Library:

Order of Target Execution

The order of execution of the targets is in the following list.

  1. BeforeEndToEndIteration

  2. BuildNumberOverrideTarget

  3. InitializeEndToEndIteration

  4. BeforeClean

  5. CoreClean

  6. AfterClean

  7. Clean

  8. InitializeBuild

  9. BeforeGet

  10. BeforeLabel

  11. Label

  12. AfterLabel

  13. InitializeWorkspace

  14. CoreGet

  15. AfterGet

  16. PreBuild

  17. BeforeCompile

  18. CoreCompile

  19. AfterCompile

  20. Compile

  21. GetChangeSetsAndUpdateWorkItems

  22. PostBuild

  23. BeforeTest

  24. CoreTest

  25. Test

  26. AfterTest

  27. PackageBinaries

  28. TeamBuild

  29. BeforeDropBuild

  30. CoreDropBuild

  31. CopyLogFiles

  32. AfterDropBuild

  33. DropBuild

  34. EndToEndIteration

  35. AfterEndToEndIteration

Let’s look at the four targets related to copying the files to the drop location (BeforeDropBuild, CoreDropBuild, AfterDropBuild, DropBuild). DropBuild is the target you would specify on the command line if you only want to drop the build to the drop location and is defined as follows:

<!– Batch target for copy –>
<Target Name=”DropBuild”
DependsOnTargets=”$(DropBuildDependsOn)” />

and the DropBuildDependsOn property looks like this:


So it’s intentially empty, because a build target can only specify on which targets it depends. So DropBuild is only a structure element to ensure Before, Core And AfterDropBuild will be invoked in the designated order.

Before and AfterDropBuild are empty as well (waiting for you to override them if you want to customize the process):

<!– Override this target to plugin custom tasks before DropBuild –>
<Target Name=”BeforeDropBuild” />

<!– Override this target to plugin custom tasks after DropBuild target –>
<Target Name=”AfterDropBuild” />

And finally CoreDropBuild does the work (and it’s recommended NOT to override this target)

<<!– Task will copy binaries and log file to drop location. Please note that this is presently for only non desktop scenarios –>
<Target Name=”CoreDropBuild”
Condition=” ‘$(IsDesktopBuild)’!=’true’ and ‘$(SkipDropBuild)’!=’true’ “
DependsOnTargets=”$(CoreDropBuildDependsOn)” >

<!– Copy output assemblies –>
<CreateItem Include=”$(BinariesRoot)\**\*.*” >
<Output ItemName=”FilesToCopy” TaskParameter=”Include” />

DestinationFiles=”@(FilesToCopy ->’$(DropLocation)\$(BuildNumber)\%(RecursiveDir)%(Filename)%(Extension)’)”
ContinueOnError=”true” />



No Comments so far ↓

There are no comments yet...Kick things off by filling out the form below.

Leave a Comment