If you have added some new Activity or CodeActivity to your build process template but you don’t want to edit template process each time you want modify properties of Activity or CodeActivity, you must add that parameter to “Build process parameters” list of your desired build definition. By doing this, there is no need to modify template process and check-in back it each time.
Jason has described this and has showed how you can do it by editing XAML file directly. But if you are searching for an easier way, follow these steps:
1. Open build process template.
2. Open Arguments tab at the bottom-left corner of the screen.
3. Add your parameters as “In” arguments.
4. Pass value of these arguments to properties of desired build/workflow activities.
5. Save and check-in template process.
6. Open up Build Definition that uses this template process.
7. Go to Process tab and navigate to Misc section. You will see your added arguments there, that are added as “Build process parameters”.
8. Fill your values there to be used by TFS Build.
If you are going to start using TFS 2010 please be aware that each TPC (Team Project Collection) needs a separate Build Controller.
For those who are intended to use TFS 2010 as their ALM engine, TFS 2010 can contain several TPCs. Each TPC can contain several Team Projects. Each Team Project is a regular space in TFS that contains Work Item Management, Source Control and Build automation. Build automation in each Team Project contains several Build Definitions that build project with several conditions. Each Build Definition is assigned to a Build Controller. A Build Controller is a build server that builds project using conditions defined in Build Definitions.
In other hands while defining a new Build Definition you must specify its Build Controller. Unfortunately with TFS 2010 you can not use Build Controller defined for say TPC number one for say TPC number two. Each TPC must have its own Build Controller.
Considering that a Build Controller is really a server, assigning a server to each TPC defined in TFS is not very applicable in most companies and teams. There is an article in MSDN blogs that shows a way to use a single Build Controller in several TPCs. As the article itself emphasis, this hack is not recommended for operational installations. Some people like us have been forced to use a single TPC for all Team projects. This work-around has many disadvantages like interfere of Team Projects, security issues, etc, but at least have solved the problem of need to several servers as Build Controllers.
My question in StackOverflow
Related content in TFS forum
Related content in GeeksWithBlogs
Jim Lamb’s hack for the problem
It was a while that I was searching a way increasing version number of a .Net assembly by each build. In the beginning there were very ambiguity for myself that I tried to solve one by one:
1. When to increase assemblies version? Each time that developer builds the project on his (her) machine? Or each time that a build occurs in Team Build? Very soon I realized that is better to use Team Build because version number in each development machine may increase separately. Additionally Team Build maintains a database of all previous build for future uses.
2. By using Team Build based solutions I was unable to use patterns such as “1.0.*” for AssemblyVersion. I was forced to modify/generate AssemblyInfo.cs or some files like VersionInfo.cs. The question was if Team Build or something like MSBuild would change AssemblyInfo.cs, how can I see version information? There are two ways: get latest version, check-out AssemblyInfo.cs/VersionInfo.cs, modify, check-in and cause build based on them or get latest version, modify AssemblyInfo.cs/VersionInfo.cs without check-out/check-in, cause build based on them. Jimb Lamb says it’s a best practice to not check-in/check-out any changes during a build. I chose Jim’s approach.
3. Should I use MSBuild or Team Build? Use MSBuild’s tasks or Team Build’s process templates and activities? The answer was dependent on how I want generate build numbers. As I wanted to use Team Build’s build number in versioning and I wanted to access the history of a each assembly version, I chose Team Build because MSBuild’s tasks are not able to save history of builds in a database.
4. How can I use Team Build 2010 to do the versioning for me? By using TfsSdk: ActivityPack. There is an activity named “UpdateVersionInfo” in the pack. You should put in the bottom of “Overall Build ProcessRun On AgentInitialize Workspace” activity just after “Get Workspace” activity. Don’t forget to add arguments FileSpec, RegularExpression and VersionInfo with proper default values. Use “$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)” as build definition’s Build Number Format as “UpdateVersionInfo” needs those extra periods. For more info refer to Jim Lamb’s blog post describing it thoroughly.
Also see this blog posts and StackOverflow’s questions: link, link, link, link, link, link, link.