Aaron Hallberg, a developer working on Team Build, has taken the plunge and started a blog. Those of you who frequent the MSDN Team Build forum will probably recognize the name. You now have a blog to go with the name!
After getting post #1 out of the way, Aaron shows you how to insert custom build step from a custom task. The build steps are the messages that are displayed in the build report window. For example, you would want to insert a build step if your custom task takes a significant amount of time, so that the person running the build has some insight into what's going on. Also, it can be useful to insert error messages as build steps if it's an important error that you want to have higher visibility.
Adding BuildSteps to Team Build through a Custom Task Team Build displays Build Steps in the build report form within Visual Studio. By default, build steps are added at various points during the course of a build - while getting sources (in the Get task), compiling solutions / projects, copying files to the drop location, etc. Team Build allows users to insert their own build steps using the publicly accessible BuildStore web service - in particular, the AddBuildStep and UpdateBuildStep methods. The following sample (I make no claims as to the awesomeness or lack thereof of this sample, etc.) TeamBuildTask class illustrates how this can be done.
Adding BuildSteps to Team Build through a Custom Task
Team Build displays Build Steps in the build report form within Visual Studio. By default, build steps are added at various points during the course of a build - while getting sources (in the Get task), compiling solutions / projects, copying files to the drop location, etc. Team Build allows users to insert their own build steps using the publicly accessible BuildStore web service - in particular, the AddBuildStep and UpdateBuildStep methods. The following sample (I make no claims as to the awesomeness or lack thereof of this sample, etc.) TeamBuildTask class illustrates how this can be done.
Last week, the folks at Vertigo Software wrote a couple of really good posts involving Team Build.
The first one, written by Jeff Atwood, is about building projects that have code shared from a different team project. The crux of the problem is that in v1 Team Build doesn't allow mappings in the Workspace.xml file to span team projects. Jeff takes Manish Agarwal's solution for builds requiring files from more than one team project and lays out a solution for dealing with VS projects that include code from other team projects.
How do I build a Team Project with shared code? One question that comes up a lot in Team System deployments is "how do I share code across team projects"? The easiest way to accomplish this is to set up a Team Project specifically for common, shared code. Here's a simple example of this scenario. We have one Team Project for ClientApp, and a second Team Project for CommonUtils. ClientApp is a console application that references CommonUtils.
How do I build a Team Project with shared code?
One question that comes up a lot in Team System deployments is "how do I share code across team projects"? The easiest way to accomplish this is to set up a Team Project specifically for common, shared code. Here's a simple example of this scenario.
We have one Team Project for ClientApp, and a second Team Project for CommonUtils. ClientApp is a console application that references CommonUtils.
The second one, written by Eric Cherng, is about using the new Web Application Projects with Team Build. His post explains what you need to download and a crucial step involving placing the WAP msbuild targets file on the build machine.
Web Application Projects in Team System While investigating a problem we were having internally with web application solutions in Visual Studio 2005 and Team Build server, I came upon the Web Application Project type for Visual Studio 2005. Wow, wish I found out about this one sooner and it was actually part of Visual Studio 2005! The new built in web application project in Visual Studio 2005 is ok, but it sure has a lot of quirkiness that makes it more troublesome than beneficial in my experience. After playing around with the new Web Application Project (WAP from now on.. no not that WAP!) for a while, I discovered a couple of tips that might help others out there.
Web Application Projects in Team System
While investigating a problem we were having internally with web application solutions in Visual Studio 2005 and Team Build server, I came upon the Web Application Project type for Visual Studio 2005. Wow, wish I found out about this one sooner and it was actually part of Visual Studio 2005! The new built in web application project in Visual Studio 2005 is ok, but it sure has a lot of quirkiness that makes it more troublesome than beneficial in my experience.
After playing around with the new Web Application Project (WAP from now on.. no not that WAP!) for a while, I discovered a couple of tips that might help others out there.
The VSTS User Education blog announced new MSDN content on using and customizing Team Build. Check it out!
New Team Foundation Build Customization Content on MSDN We are adding new content on explaining Team Founadation Build customization targets and tasks. Check out the following topics on MSDN: Understanding Team Foundation Configuration Files Customizable Team Foundation Build Targets Customizable Team Foundation Build Properties Team Foundation Build Tasks Additionally, a walkthrough that explains how to build a Visual Studio setup project in Team Foundation Build is posted at: Using Team Build to Build a Visual Studio Setup Project
We are adding new content on explaining Team Founadation Build customization targets and tasks.
Check out the following topics on MSDN:
Understanding Team Foundation Configuration Files
Customizable Team Foundation Build Targets
Customizable Team Foundation Build Properties
Team Foundation Build Tasks
Additionally, a walkthrough that explains how to build a Visual Studio setup project in Team Foundation Build is posted at:
Using Team Build to Build a Visual Studio Setup Project
Carl Daniel (code) and Robert Downey (code) each wrote and posted code to show the changesets between two labels in TFS version control. They each took the same basic approach: call QueryLabels() to get the set of items in each label, find the highest changeset version for each set of items, and then call QueryHistory() with the range of versions specified as the two highest changeset versions found.
There's one technical flaw with this approach. A label in Team Foundation Server is not a point in time. In TFS labels are collections of files, each at a particular version. Brian Harry wrote about this difference in a post titled, Why TFS labels aren't like SourceSafe labels.
In Team Foundation, labels are more powerful. Instead of being a single point in time, they are able to have versions of each file in the label from different points in time. The canonical scenario is that you label a build and then find some bugs and want to go back change the versions of a few of the files (either omitting changes that introduced bugs or adding changes that fixed bugs). Now the label does not represent a point in time, but rather a collection of points in time. This makes it very hard to display it in a list mixed with change sets because there is not “correct” ordering of the list. As a result we treat the list of changesets and the list of labels separately.
Another very common approach is creating a label using the versions of files in a workspace. A workspace is also a collection of files, each potentially from a different point in time. Team Build labels the files in its workspace as part of the build process. By doing this Team Build guarantees that it is labeling what it's building. Steve St. Jean talks about this in his post, Why I Like Labels in TFS Version Control.
By finding the highest changeset in each label to compute the differences, the label is inherently being represented at a point time, as a changeset is just a precise point in time with respect to the state of the repository. As a result, the report produced by these apps won't necessarily be completely accurate if the label has been changed, such as Brian describes in his example, or the label was based on the versions in a workspace where not all versions are from the same point in time.
Computing the actual set of changes between two labels, taking into account that labels are not points in time, becomes a much more expensive computation involving computing the history of each item between the two changesets in the label (and handling adds and deletes). In fact, the GenCheckinNotesUpdateWorkItems task in Team Build takes this fully accurate approach, and it's why that task is so slow (see GenCheckinNotesUpdateWorkItems task is expensive and Measuring Performance of Team Build Build Process). By the way, you can set SkipPostBuild to true in your TfsBuild.proj (add this line: <SkipPostBuild>true</SkipPostBuild>) file to prevent that task from running if you find it too expensive and don't need the changesets and work items recorded in the build information and the "fixed in field" updated in those same work items.
So, should you go with the fast approach used by Carl and Robert or take the slow approach used by Team Build? The answer depends on whether your labels are points in time and what level of accuracy you need when determining what's changed between two labels. The approach used by Carl and Robert is completely accurate if your labels are strictly points. If you need complete accuracy and your labels are not points in time, you'll need the more expensive approach. If you don't need complete accuracy, the fast approach may give an answer that's "close enough" for what you are doing.
For three years I worked on Team Foundation Server Version Control. Most of my contributions were to the version control object model, the tf.exe command line, and general infrastructure. After v1 shipped in March, we reorganized the TFS organization.
Version 1 of TFS Team Build was developed by a small team in India, led by Gautam. As part of the April reorganization, the Team Build feature moved to North Carolina, and I became the dev lead. It's still a small team, compared to version control and work item tracking.
Durham, North Carolina is now home to the build automation, version control, and administration & operations teams. The work item tracking, reporting, and office integration teams reside in Redmond. The office has grown to the point that it's basically a 50/50 split with Redmond.
I've been trying to keep track of blogs that have posts about Team Build. If you blog about Team Build, please leave a comment on this post or contact me so that I can subscribe. If you have specific feedback on features you need to be more productive or event to consider using Team Build (yes, we know that happens), post a trackback to this post or contact me.
If you have questions, the MSDN Team Build forum is a great place to get answers, both from the team at Microsoft and from the community.
If you noticed a while back that I changed my blog's subtitle, reorganized my links to Team Foundation blogs, and started writing about Team Build, you now know why. And just in case you are wondering, I'll still write about version control as well.
A check-in policy to require a comment has always been a frequent request. Jeff Atwood has posted a convenient installation package (.msi) for James Manning's check-in policy to require a comment.
Installing the Check for Comments Check-In Policy In a previous entry on adding a new check-in policy, I provided the source code for a comment policy. I re-packaged that source into an easy one-click installer: Download the Team System Check for Comments Policy installer (140kb) Download the Team System Check for Comments source code (11kb)
Installing the Check for Comments Check-In Policy
In a previous entry on adding a new check-in policy, I provided the source code for a comment policy. I re-packaged that source into an easy one-click installer:
As some customers have found out the hard way, the TFS release candidates have started to expire without warning at the end of the 6 month (180 days) period. The TFS trial edition (RTM) will start to expire next month, again without warning. It also expires 6 months after installation.
This morning, Brian Harry posted a tool that you can use to detect which version of Team Foundation Server you have installed and when it will expire.
More Expirations Coming Soon... A couple of weeks ago I wrote about the impending expirations of TFS Release Candidate installations and Trial installations that were installed soon after release. Both the TFS Release Candidate and the TFS Trial Edition have 6 month expiration periods. Many of the Release Candidate builds started expiring this month. Trial Editions will start expiring in September.
More Expirations Coming Soon...
A couple of weeks ago I wrote about the impending expirations of TFS Release Candidate installations and Trial installations that were installed soon after release. Both the TFS Release Candidate and the TFS Trial Edition have 6 month expiration periods. Many of the Release Candidate builds started expiring this month. Trial Editions will start expiring in September.
I've written before about putting files directly into Outlook to make them securely available at work and at home. Part of the reason for that is to have documents that just contain my thoughts on changes we should make, features we should consider, and so on. Those are the kinds of things that would fit well into OneNote. But I can't get to OneNote in all the places where I have access to Outlook.
Omar Shahine wrote a post today titled, Outlook Wish List 2007. In it he mentions wanting to see OneNote integration with Outlook. That would be really useful, and I'd start using OneNote if I could see the same OneNote view at home and at work via Outlook. If either of those teams is listening, here's another vote for it.
Replace Notes with OneNotes. I've never understood Outlook Notes. They don't have a scroll bar, look like sticky notes, and are in a weirdo font. You also don't have a toolbar and can't easily assign a category to them. Lets put Notes out to pasture and integrate the excellent note taking app OneNote directly into Outlook so that my notes can roam and be viewable in OWA. Mike Torres weighs in on this and I have to agree with many of his points. The fact that OneNote doesn't work in a web browser, or doesn't roam from PC to PC w/o something like FolderShare is a major hindrance for me. The fact that OneNote for PPC and Smartphone can't sync over the air like tasks, contacts, calendar and mail is an even bigger bummer.
I tried using an RSS aggregator, but it didn't fit the way that I wanted to work. All of the feeds are trapped on the machine running the aggregator. I wanted to be able to get to them from work and home. Web-based aggregators solve that issue but still fell flat for me because I never remembered to go check them. I wanted something that would deliver everything to me in the one application that I have access to from work and home (RPC over HTTP) and that I run all of the time: Outlook.
Rob Caron told me about Squeet when I was in Redmond in March, and I started using it then and never looked back. Squeet is a web site where you can subscribe to RSS feeds, and it emails you the posts from the feed. And they have a little browser add-in (IE and Firefox) so that all you have to do to subscribe to an RSS feed on a web page is hit the green button (I've installed it on every machine where I use IE). I set up one rule in Outlook to send the emails to my Blog Feeds folder (anything from DoNotReply@squeet.com), and I've been happily reading blogs ever since. I can flag a post in Outlook, forward it to someone, or delete it when I'm done with it. And I get the same consistent view in Outlook at home.
Here's what a post looks like. It has the formatting and images of the original post.
I really think Squeet rocks. It's the one thing that has met my needs for keeping up with the blogs that I read.
Build systems need to do all sorts of things, from updating web sites to deploying databases. Often, the tasks needed to do these things are available, but finding them can be a challenge. I've collected links to various MSBuild task collections that you can plug into your Team Build scripts. Hopefully, you'll find something that helps you get more out of your build.
[UPDATE 5/30/2007] The SDC Tasks Library that was on GotDotNet is now on CodePlex at http://www.codeplex.com/sdctasks.
I stumbled across the following pages on MSDN that provide step-by-step introduction to the basics of extending Team Foundation Server.
[UPDATE 8/29/06] Unfortunately, all of the links originally pointed to the same page, and I've now fixed them. I didn't notice at the time that clicking on different links on that section of the msdn tree doesn't change the URL in the browser, so I copied the same one every time. Thanks, Tom, for letting me know!
I recently had to put together a list of links to code samples. This isn't even close to comprehensive, but it should help you get going if you are looking for something.
Version Control
TFS
Work Item Tracking
On internal mailing list, someone asked how to do this, and I thought it's worth sharing. You can get a Changeset object using its artifact URI (aka link) via VersionControlServer.ArtifactProvider. Here’s how that would look like, based on modifying code from James Manning’s blog posthttp://blogs.msdn.com/jmanning/archive/2005/09/21/472524.aspx. Added/changed lines are hightlighted.
using System;using System.Collections.Generic;
using Microsoft.TeamFoundation.Client;using Microsoft.TeamFoundation.WorkItemTracking.Client;using Microsoft.TeamFoundation;using Microsoft.TeamFoundation.VersionControl.Client;
class ChangesetsFromWorkItems{ static void Main(string[] args) { if (args.Length < 2) { Console.Error.Write("Usage: ChangesetsFromWorkItems <server> <workitemid> [workitemid...]"); Environment.Exit(1); }
TeamFoundationServer server = TeamFoundationServerFactory.GetServer(args[0]); WorkItemStore wiStore = (WorkItemStore)server.GetService(typeof(WorkItemStore)); VersionControlServer vcs = (VersionControlServer) server.GetService(typeof(VersionControlServer));
int workItemId; for (int i = 1; i < args.Length; i++) { if (!int.TryParse(args[i], out workItemId)) { Console.Error.WriteLine("ignoring unparseable argument {0}", args[i]); continue; }
WorkItem workItem = wiStore.GetWorkItem(workItemId); List<Changeset> associatedChangesets = new List<Changeset>(); foreach (Link link in workItem.Links) { ExternalLink extLink = link as ExternalLink; if (extLink != null) { ArtifactId artifact = LinkingUtilities.DecodeUri(extLink.LinkedArtifactUri); if (String.Equals(artifact.ArtifactType, "Changeset", StringComparison.Ordinal)) { // Convert the artifact URI to Changeset object. associatedChangesets.Add(vcs.ArtifactProvider.GetChangeset(new Uri(extLink.LinkedArtifactUri); } } }
// Do something with the changesets. Changes property is an array, each Change // has an Item object, each Item object has a path, download method, etc. } }}
In addition to the MSBuild documentation on MSDN and the MSBuild team blog, there is an MSBuild wiki on Channel9. I had seen it before, but forgotten about it until I saw it mentioned in one of Chris Sells' old blog posts (My First MsBuild Task).
Here's the current table of contents for the wiki.
Frequently Asked Questions General Project File Format Shipping Tasks Loggers Tasks VS / MSBuild Integration Conversion MSBuild.exe Command Line Object Model Scenarios Does Microsoft use MSBuild to build its own products? How to execute CS templates from MSBuild? External Links and Resources Quick Start Tutorials Write a simple project Clean my Build Specify which Target to Build First Build All Files in a Directory Build All Files in a Directory Except One Build the Same Sources with Different Options Use Environment Variables in a Build Check whether an Environment Variable has been set Build a Project with Resources Build Incrementally Use the Same Target in Multiple Project Files Tell MSBuild to Ignore Errors in Tasks Extend MSBuild with a New Task Build a Set of Dependant Projects Run a Custom Tool From my Project Specify Several Build Options on the Command Line Use Reserved XML Characters in Project Files Display an Item List Separated with Commas Convert an Item List into a scalar string Reference the Name or Location of the Project File in the Project File How do I do a recursive copy? Batching Examples MSBuild Specifications How the batching algorithm works How to find targets files in a canonical place MSBuild Community Wish List
Frequently Asked Questions
There have been several times when folks have needed to run a custom target prior to building each solution (or project) in Team Build. Unfortunately, there's no good way to do this. Manish Agarwal describes (mostly) how to do it in his post, How to call a custom target after building each individual solution (sln) in Team Build? The solution he gives involves overriding the CoreCompile target.
The CoreCompile target, along with many other Core* targets, is changing for the next release of Team Foundation Server. The changes are due to the need to support new features in the product, along with greater flexibility. So, if you go that route, you will need to adjust your build files down the road when you upgrade to the next release. For a list of targets that you can safely override, see Team Build Extensibility.
One bit of good news is that we are working to address this in a future release and make it possible to cleanly inject your targets before or after (or both!) each solution is built.
One user, Steve St. Jean, describes his experience with this trying to do this. He ultimately was able to take a different approach to solve his problem.
Here are a few more useful tips from Steve's blog.
Hopefully, he won't have to add "by Team Build" to his blog's title, "How Steve Got Burned Today."
Jeff Atwood has a nice post on how to get Team Build to put the build number in the assemblies it builds.
Adding the Build Number to your Team Build binaries If you're using Team Build, you may want to "tag" the binaries produced with the name of the build. In order to do this, we'll customize the Team Build script (TFSBuild.proj) for the project, hooking in to the default Team Build BeforeCompile event.
Adding the Build Number to your Team Build binaries
If you're using Team Build, you may want to "tag" the binaries produced with the name of the build.
In order to do this, we'll customize the Team Build script (TFSBuild.proj) for the project, hooking in to the default Team Build BeforeCompile event.
Back in April, Mariano Szklanny posted a tip on how to get intellisense in VS when editing the XML for a work item type.
If you’re editing work item types, you will find useful having Intellisense in Visual Studio 2005: Open the Visual Studio Team System Integration folder from the VS 2005 SDK. The SDK can be downloaded from here. Navigate to Work Item Tracking. Copy the file WorkItemTypeDefinition.xsd included in Work Item Tracking Schemas.zip to "C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas", supposing you installed VS 2005 in the default location.
If you’re editing work item types, you will find useful having Intellisense in Visual Studio 2005:
Earlier, I mentioned Jeff Atwood's continuous integration approach. Here are a couple more approaches.
Sondre Bjellås has decided to write his own continuous integration system for Team Build back in May (Making a Team System Automation Framework). It is called Automaton, and it's available on CodePlex.
Automaton is a Continuous Integration engine for Microsoft Team Foundation Server. Automaton will monitor your source code repository and automatically run the correct team builds that you create within Visual Studio. Build reports can be view through a web site, and your development team can get notifications on e-mail or MSN Messenger when there is problem building the source code. Automaton supports Visual Studio 2005 and Team Foundation Server. Automaton supports only the use of Team Foundation Source Control, there is currently no support for Visual Source Safe. Automaton is available for free and source code is licensed under Shared Source License.
Automaton is a Continuous Integration engine for Microsoft Team Foundation Server. Automaton will monitor your source code repository and automatically run the correct team builds that you create within Visual Studio. Build reports can be view through a web site, and your development team can get notifications on e-mail or MSN Messenger when there is problem building the source code.
Automaton supports Visual Studio 2005 and Team Foundation Server. Automaton supports only the use of Team Foundation Source Control, there is currently no support for Visual Source Safe.
Automaton is available for free and source code is licensed under Shared Source License.
In the March 2006 issue of MSDN Magazine, Ben Waldron wrote an article about his approach. His article includes the implementation as well.
Extend Team Foundation Server To Enable Continuous Integration Many development teams have adopted "agile" methodologies to manage change and to improve software quality. These methodologies promote continuous integration as a practice to build and test software products incrementally as new features are included, bugs are fixed, and code is refactored. So how does Visual Studio® 2005 Team System and Team Foundation Server facilitate the process of agile development and continuous integration? This article answers that question by creating an example project using agile concepts such as test-driven development (TDD) using the new unit testing features in Visual Studio 2005 Team System. After the project is completed, I'll show how to create a team project using Team Foundation Server and use this technology's extensibility features to build a custom Web service that enables continuous integration to build the application as code is checked into source control.
Extend Team Foundation Server To Enable Continuous Integration
Many development teams have adopted "agile" methodologies to manage change and to improve software quality. These methodologies promote continuous integration as a practice to build and test software products incrementally as new features are included, bugs are fixed, and code is refactored. So how does Visual Studio® 2005 Team System and Team Foundation Server facilitate the process of agile development and continuous integration?
This article answers that question by creating an example project using agile concepts such as test-driven development (TDD) using the new unit testing features in Visual Studio 2005 Team System. After the project is completed, I'll show how to create a team project using Team Foundation Server and use this technology's extensibility features to build a custom Web service that enables continuous integration to build the application as code is checked into source control.
[Update 10/22/06] Since I wrote this post, new continuous integration add-ons have been released.
TFS Integrator by Readify
Continuous Integration (CI) is the process of continually scanning the source code repository for changes, and, once they have been detected automatically kicking off a build process to verify that the code compiles successfully. When TFS Integrator initialises it reads a configuration file to identify which parts of the source tree it is interested in listening to then subscribes to the check-in event notifications that the eventing system sends out. When it receives a notification it sleeps for a specified period of time then kicks off a build with the Team Build facility. Once the build is completed the eventing system sends how a notification to subscribers as to the outcome.
Continuous Integration (CI) is the process of continually scanning the source code repository for changes, and, once they have been detected automatically kicking off a build process to verify that the code compiles successfully.
When TFS Integrator initialises it reads a configuration file to identify which parts of the source tree it is interested in listening to then subscribes to the check-in event notifications that the eventing system sends out.
When it receives a notification it sleeps for a specified period of time then kicks off a build with the Team Build facility. Once the build is completed the eventing system sends how a notification to subscribers as to the outcome.
TeamCI by Notion Solutions
Because “Team Build”, Team Foundation Server’s Build Server, does not include any out-of-the-box mechanism to automatically start a build when a user checks files into the Source Control System, users have to manually start those builds on a regular basis. TeamCI makes this cumbersome task as easy as it can be, with a user interface that helps users quickly configure which builds execute and enables them to execute builds based on the path in the Source Control repository to which files are being checked in. What that means is that it is “smart” enough to sequentially launch one or more Team Builds based on the location of the file(s) being checked-in. Note: Must be installed on the TFS Application-tier server. Documentation has not yet been released, check out the TeamCI Forum for updated info.
Because “Team Build”, Team Foundation Server’s Build Server, does not include any out-of-the-box mechanism to automatically start a build when a user checks files into the Source Control System, users have to manually start those builds on a regular basis. TeamCI makes this cumbersome task as easy as it can be, with a user interface that helps users quickly configure which builds execute and enables them to execute builds based on the path in the Source Control repository to which files are being checked in. What that means is that it is “smart” enough to sequentially launch one or more Team Builds based on the location of the file(s) being checked-in.
Note: Must be installed on the TFS Application-tier server. Documentation has not yet been released, check out the TeamCI Forum for updated info.
This one is an article on DevX.com: Add Continuous Integration Capabilities to Team Foundation Server
Continuous Integration is an agile process that rebuilds a project whenever the underlying code changes. Find out how to modify your Team Foundation Server projects' "build types" to implement continuous integration features such as automatic builds, testing, and problem notification. by Michael Jones
Continuous Integration is an agile process that rebuilds a project whenever the underlying code changes. Find out how to modify your Team Foundation Server projects' "build types" to implement continuous integration features such as automatic builds, testing, and problem notification.
by Michael Jones
Eric Charran has written a nice post on dealing with ClickOnce manifests in Team Build.
Building a ClickOnce Manifest File with Team Foundation Services Team Build Issue: When building a ClickOnce application using Team Foundation Build Services, the goal is to modify the details contained within the .application deployment manifest file to conform to desired settings segregated by build type. This would allow Build Masters and Release Managers to build the application using different build types within Team Foundation Server and have the drops for those builds take on different deployment profiles. For example, the deployment URL for a specific debug drop would be different than its production companion. In order to change this, the information within the project can be altered so that the build process honors the settings, but this approach is not maintainable (i.e., every time the project is build, a developer has to manually edit the .csproj or .vbproj’s ClickOnce deployment settings).
Building a ClickOnce Manifest File with Team Foundation Services Team Build
Issue:
When building a ClickOnce application using Team Foundation Build Services, the goal is to modify the details contained within the .application deployment manifest file to conform to desired settings segregated by build type. This would allow Build Masters and Release Managers to build the application using different build types within Team Foundation Server and have the drops for those builds take on different deployment profiles. For example, the deployment URL for a specific debug drop would be different than its production companion. In order to change this, the information within the project can be altered so that the build process honors the settings, but this approach is not maintainable (i.e., every time the project is build, a developer has to manually edit the .csproj or .vbproj’s ClickOnce deployment settings).
Jeff Atwood started out with the continuous integration with MSDN CI sample for Team Build. Then he made improvements to it and posted it as a A Kinder, Gentler Continuous Integration service for Team Foundation Server. You can use Abhinaba's build notification tools to keep track of how it's going.
A Kinder, Gentler Continuous Integration service for Team Foundation Server In an earlier post, I documented how to set up Microsoft's unofficial Continuous Integration solution for Team System. I was a little.. perplexed.. by the code inside that web service. I took some time to refactor it and polish it up into something I personally found much simpler and easier to understand. For example, I added proper XML comments throughout, and made the log file more visible and timestamped. It's still 99% the product of Khushboo's hard work, don't get me wrong, but this is a kinder, gentler version of the Continuous Integration web service you could deploy to your Team Foundation Server with the confidence that you could easily modify it if you needed to.
In an earlier post, I documented how to set up Microsoft's unofficial Continuous Integration solution for Team System.
I was a little.. perplexed.. by the code inside that web service. I took some time to refactor it and polish it up into something I personally found much simpler and easier to understand. For example, I added proper XML comments throughout, and made the log file more visible and timestamped.
It's still 99% the product of Khushboo's hard work, don't get me wrong, but this is a kinder, gentler version of the Continuous Integration web service you could deploy to your Team Foundation Server with the confidence that you could easily modify it if you needed to.
Abhinaba Basu posted his second Team Build power toy build notification app. Previously he had posted a Team Build RSS feed power toy. Today he posted his desktop notification app, which he calls BuildTicker.
Team Build Ticker: parting gift I had blogged earlier about the BuildTicker tool which sits on the system tray and notifies of builds happening on the server. I have received many requests to get this tool. So here it goes. Get the executable from here and the sources from here. Since I am no longer working on the TFS team you can consider this as my parting gift :)
Team Build Ticker: parting gift
I had blogged earlier about the BuildTicker tool which sits on the system tray and notifies of builds happening on the server. I have received many requests to get this tool. So here it goes. Get the executable from here and the sources from here. Since I am no longer working on the TFS team you can consider this as my parting gift :)
There's a document in the Visual Studio 2005 SDK that describes the extensibility points in Team Build. I have the April release of the SDK, so it's located at C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioTeamSystemIntegration\Team Build\Team Build Extensibility.doc.
The SDK is a huge download, so I'm attaching the document to this blog post.
Here's what's covered in the document.
One useful piece of information is the order in which the targets are executed. I've copied that section below, and the ones marked with an asterisk are specifically designed to be overridden for adding custom behavior (overriding the Core* targets may result in you needing to fix your project files when future versions are released).
1. BeforeEndToEndIteration*2. BuildNumberOverrideTarget*3. InitializeEndToEndIteration4. BeforeClean*5. CoreClean6. AfterClean*7. Clean8. InitializeBuild9. BeforeGet*10. InitializeWorkspace11. CoreGet12. AfterGet*13. PreBuild14. BeforeCompile*15. CoreCompile16. AfterCompile*17. Compile18. GetChangeSetsAndUpdateWorkItems19. PostBuild20. BeforeTest*21. CoreTest22. AfterTest*23. Test24. PackageBinaries*25. TeamBuild26. BeforeDropBuild*27. CoreDropBuild28. CopyLogFiles29. AfterDropBuild*30. DropBuild31. AfterEndToEndIteration*32. EndToEndIteration The targets marked by an “*” are those defined for extensibility and you should plug in your tasks using one of these depending on your need. It is not recommended to modify other targets because Team Foundation Build calls its own pre-defined tasks in those other targets.
1. BeforeEndToEndIteration*2. BuildNumberOverrideTarget*3. InitializeEndToEndIteration4. BeforeClean*5. CoreClean6. AfterClean*7. Clean8. InitializeBuild9. BeforeGet*10. InitializeWorkspace11. CoreGet12. AfterGet*13. PreBuild14. BeforeCompile*15. CoreCompile16. AfterCompile*17. Compile18. GetChangeSetsAndUpdateWorkItems19. PostBuild20. BeforeTest*21. CoreTest22. AfterTest*23. Test24. PackageBinaries*25. TeamBuild26. BeforeDropBuild*27. CoreDropBuild28. CopyLogFiles29. AfterDropBuild*30. DropBuild31. AfterEndToEndIteration*32. EndToEndIteration
The targets marked by an “*” are those defined for extensibility and you should plug in your tasks using one of these depending on your need. It is not recommended to modify other targets because Team Foundation Build calls its own pre-defined tasks in those other targets.
[Update] I just noticed that Eric Charran has a similar post from earlier this week. He points to the MSDN docs that provide a short explanation for each: http://msdn2.microsoft.com/en-us/library/aa337604.aspx.