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.
It's a horor scenario you probably don't really like to think of: You install Service Pack 1 on your production Team Foundation Server and from that moment on all connections (even from the server machine) result in one of the errors stated in the title of this post... if this is the cast: this is probably not your day!
The good news:
- You are not alone!
- There is help (a workaround)!
The Workaround:
- Change the directory security in ISS from "deny access" to "granted access".
- Change the TFS SQL server databases (TfsActivityLogging, TfsBuild, TfsIntegration, and TfsVersionControl) from SINGLE_USER to MULTI_MODE.
- Restart IIS - and you should be fine.
The Disclaimer:
Use at your own risk! Although it worked for me, it doesn't neccessarily work for you as well!
The Background:
The Quiescence patch for TFS changed IIS's directory security to "deny access" and the switched the databases from MULTI_MODE to SINGLE_USER that no data corruption occures during the update process. For some reason this is in some cases not reverted automatically. Microsoft is investigating the issue and preparing to create a fix.
Other Threads
Good luck!
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