Posts

*** The sample build process template discussed in this post is available for download from here: http://cid-ee034c9f620cd58d.office.live.com/self.aspx/BlogSamples/ILMerge.xaml *** In my previous post I talked about library builds that we use to build and replicate dependencies between applications in TFS. This is typically used for common libraries and tools that several other application need to reference. When the libraries grow in size over time, so does the number of assemblies. So all solutions that uses the common library must reference all the necessary assemblies that they need, and if we for example do a refactoring and extract some code into a new assembly, all the clients must update their references to reflect these changes, otherwise it won’t compile. ...

Some time ago, I wrote a post about how to implement dependency replication using TFS 2008 Build. We use this for Library builds, where we set up a build definition for a common library, and have the build check the resulting assemblies back into source control. The folder is then branched to the applications that need to reference the common library. See the above post for more details. Of course, we have reimplemented this feature in TFS 2010 Build, which results in a much nicer experience for the developer who wants to setup a new library build. Here is how it looks: There is a separate build process template for library builds registered in all team projects \ ...

Update 15.03.2014 - Fixed broken link to download *** The custom activity is availabe for download here: https://onedrive.live.com/redir?resid=EE034C9F620CD58D%21168 *** Often when creating different types of release builds (e.g. where you build something that should be installed or consumed by other applications) there is a need to check in the results of the build back to source control. A common build type for us at Inmeta is Library Builds, which we use for common libraries that are shared among several applications. We have created a special build process template for this scenario that handles versioning, copying of the resulting binaries to a pre-defined folder, optionally merges the assemblies using ILMerge, and finally checking that binaries back to TFS as part of the build. ...

One of the great new features in TFS 2010 Build was the ability to define Build Process Templates that can be reused across build definitions. The Build Process Template file itself is a Windows Workflow 4.0 xaml file and can be stored anywhere in source control. When a developer creates a new build definition in Team Explorer, he can choose from a list of Build Process Templates: This list is populated with the following build process templates: ...

Update 2012-01-23: Added note about .NET framework Martin Hinshelwood wrote an excellent post recently http://nakedalm.com/team-foundation-server-2010-event-handling-with-subscribers/ ) about a new type of integration available in TFS 2010, namely server side event handlers, that is executed within the TFS context. I wasn’t aware of this new feature and as Martin notes, there doesn’t seem to be any material/documentation of it at all. Previously, when you wanted some custom action to be executed when some event occurs in TFS (check-in, build completed…) you wrote a web/WCF service with a predefined signature and subscribed to the event using bissubscribe.exe. Usually you want to get more information from TFS than what is available in the event itself so you would have to use the TFS client object model to make new requests back to TFS to get that information. The deployment of these web services is always a bit of a hassle, especially around security. Also there is no way to affect the event itself, e.g. to stop the event from finishing depending on some condition. This can be done using server side events. ...

In TFS 2010, branching and merging have been greatly improved with support for branch visualization and tracking of changesets and work items across branches. A simple example of this looks like this: \ Here we track Work Item nr 3 which was originally resovled in the Test branch (with changeset 35). We can also see that the work item has been merged into the Production branch (as changeset 37), back to Main (62) and finally to FeatureC (140). If we switch to the Timeline view, we get a nice view of the order of these merges, together with the dates. ...

In TFS 2010, I have been asked this question several times: I have a build setup with tests and (possibly) code coverage, but in the build summary report it only shows No Test Results and No Code Coverage Results What’s more interesting is that when I log in and view the build, I can see the test results! This does of course imply that it is a one of those annoying security issues, and of course it is. To be able to see test results you must have the View Test Runs permission, which can be assigned/revoked at the security group level per team project: ...

Note: Swedish post Efter att ha kört många seminarier, workshops och deep dive kurser på Visual Studio och TFS 2010 i Norge är det nu äntligen dags för oss att köra kurs i Sverige! Första tillfället blir nu i oktober på Cornerstone 18-21 Oktober. Saxat från kursbeskrivningen: T359 - Effektiv systemutveckling med Visual Studio och Team Foundation Server 2010 I denna utbildning lär vi dig hur du och din organisation kan effektivisera systemutvecklingsprocessen med hjälp av Visual Studio och Team Foundation Server. Målgruppen för denna kurs är främst utvecklare och arkitekter men den är lämplig även för testare och den som ansvarar för metoder och processer. ...

By default, TFS Team Build creates a new folder in the drop location for every build. I have seen request from people that wonder how to always have team build put the output in the same folder every time, effectively overwriting the results from the last build. This is easy to accomplish by adding an activity that copies the drop folder to a fixed location. To copy the result of the build to a fixed location, you need to modify the build process template: ...

Recently I’ve come across this error a couple of times when running builds that exeucte unit tests using Test containers: API restriction: The assembly ‘file:///C:Buildsmyassembly.dll’ has already loaded from a different location. It cannot be loaded from a new location within the same appdomain. Every time I’ve got this error, the project has been a web application, and the path to the assembly points down to the _PublishedWebsites directory that is created beneath the Binaries folder during a team build. ...