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

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:

<PropertyGroup>
  <DropBuildDependsOn>
    BeforeDropBuild;
    CoreDropBuild;
    CopyLogFiles;
    AfterDropBuild;
  </DropBuildDependsOn>
</PropertyGroup>

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” />
</CreateItem>

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

</Target>

How to implement ‘blocked’ Work Items if you are waiting for someone else

A Work Item is blocked since you are waiting for someone else? Or maybe someone else is blocked and waiting for you to deliver something?


These are always problematic situations which might result in issues not getting fixed because someone didn’t know you were waiting for him.


With Work Items in Team Foundation Server you can build a solution where it is clearly documented who is waiting for whom and on the other hand you can see who is waiting for you.


All you need is a custom Work Item Type, a customized query and some notifications. MVP Ognjen Bajic shows you how: in this blog post. Enjoy!

[MS Project Integration] Open work items right inside of MS Project

Working inside of MS Project and getting your data synchronized with TFS is a great thing. But there might be a reason why you want to access the work item details form and until now you needed to start Visual Studio 2005, invoke the Team Explorer, look for the exact same work item etc.

Ognjen Bajic, a fellow VSTS MVP, made that easier for uns with his great add-in for MS Project.

If you use MS Project today to work with TFS you’ll love it.

Managing Test Lists with Visual Studio Team Edition for Software Developers using Ekobit Test Manager

As you probably know the Test Manager within, which is needed to create test lists for your build process and/or check-in policies, is only available in the Visual Studio Team Edition for Software Testers.

Ognjen Bajic has the solution:

Earlier today Ekobit (www.ekobit.com) released “Test Manager Add-In for Visual Studio Team Edition for Software Developers”.  This Add-In makes it possible for developers to manage the lists of tests, build hierarchies and execute tests from the Team Edition for Software Developers just the way they would be able to do using the Test Manager window if they had Team Suite.  Being a VSIP package, Test Manager Add-In is seamlessly integrated in the Visual Studio environment and works as a part of the Visual Studio Team System integrated testing framework.

More on Test Manager Add-In can be found here: http://www.ekobit.com/testmngr.aspx

Download free trial here: http://www.ekobit.com/download_testmngr.aspx

Microsoft Knowledge Base-Articles for Visual Studio Team Edition for Database Professionals

Although the Visual Studio Team Edition for Software Developers is a relatively new product addition of the Team System product family there a quite a lot of articles waiting for you to read in the Microsoft Knowledge Base: