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.
-
BeforeEndToEndIteration
-
BuildNumberOverrideTarget
-
InitializeEndToEndIteration
-
BeforeClean
-
CoreClean
-
AfterClean
-
Clean
-
InitializeBuild
-
BeforeGet
-
BeforeLabel
-
Label
-
AfterLabel
-
InitializeWorkspace
-
CoreGet
-
AfterGet
-
PreBuild
-
BeforeCompile
-
CoreCompile
-
AfterCompile
-
Compile
-
GetChangeSetsAndUpdateWorkItems
-
PostBuild
-
BeforeTest
-
CoreTest
-
Test
-
AfterTest
-
PackageBinaries
-
TeamBuild
-
BeforeDropBuild
-
CoreDropBuild
-
CopyLogFiles
-
AfterDropBuild
-
DropBuild
-
EndToEndIteration
-
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>
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!
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.
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