Create simple CodeActivity for TFS Build 2010

Sometimes that you need to customize TFS Build 2010, you need to create a custom CodeActivity. A CodeActivity is written in C# and you can do what you can’t in TFS Build itself, there. The simplest way to create a custom CodeActivity, deploy and use it, is as follow:

1. Create a .Net 4.0 based Class Library project. CodeActivity exists in .Net framework 4.0 only.

2. Add a Code Activity to it by right click on the project, select Add New Item and navigating to Workflow tab.

3. Add a reference to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEReferenceAssembliesv2.0Microsoft.TeamFoundation.Build.Client.dll”.

4. Add “[BuildActivity(HostEnvironmentOption.All)]” as your CodeActivity’s class attribute.

5. Add desired arguments and codes.

6. Build the project.

7. Copy generated dll to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies”. If you don’t do this, you will not be able to use Visual Studio to add your CodeActivity to any build process template.

8. Add generated dll to a specific location in TFS Source Control.

9. Open up your desired build process template.

10. Add generated dll to the toolbox by right clicking on empty space in General tab, select “Choose Items…”, click Browse, navigate to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies” again and select your generated dll. After this you will see your CodeActivity there.

11. Drag Code Activity on the desired placed in process template.

12. Add any arguments that you want to be accessed via Build Definition to the template process and pass them to your CodeActivity’s arguments. To add any arguments to a template process, open Arguments tab in the bottom-left corner of the screen and add them there.

13. Check-in template process. If you don’t so, you will not see your added arguments in Process tab of build definitions.

14. Open Build Definition that uses this build process template. You will see any arguments that you have previously added to build process. You can set any value in them.

Note: Above addresses are based on a x64 installation.
Note: For more info refer to Jim’s guide and Ewald’s guide.

Custom workflow activity’s problem with Visual Studio designer

After reading Jim Lamb’s guide for creating a custom workflow activity for TFS Build 2010, I created a project to create my own custom workflow activity too, by following Jim’s guides line by line. At the end, despite my correct custom activity, when I tried to use that in a typical template process by dragging it onto the workflow I just saw a deny symbol and couldn’t put my activity on that workflow.

After so many verifications of my custom activity and so many googling, I decided to add my activity by editing XAML file directly in notepad. Unfortunately when loaded the workflow in the Visual Studio again, a red label with message “Activity could not be loaded because of errors in the XAML.” was showing instead of my activity. So googled again and found Ewald Hofman’s solution. Based on his guides I installed my assembly in GAC and the red error message label disappeared. I was having still 2 more problems. First, Jim’s sample code was working with no problem, but my activity needed registration in GAC. Second, despite of disappearing red label, I was still unable to drag my activity to workflows, I was forced to edit XAML file directly.

After a whole challenging day, I realized that Jim’s sample assembly exists in C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies previously! I don’t know how Jim’s ActivityPack has gone to that location but I know when I copied my custom activity’s assembly to that location, my 2 problem solved too. So I could use Visual Studio designer to drag my custom workflow activity into any workflow or template process I want.

Customizing build process in TFS 2010

If you ever has need to customize build process in Team Foundation Build 2010, you may noticed that there is several ways to do it while each way is suitable for a specific range of requirements:

1. Running external tools like batch files or ftp.exe or MSBuild Community Tasks via InvokeProcess or via MSBuild Activity.

2. Invoke .Net classes and methods like System.IO.File.Delete() via InvokeMethod.

3. Creating your own custom workflow activity for TFS Build 2010.

For our specific need that is synchronizing a remote server via FTP, none of first 2 ways is suitable. In first way, running external programs, this is very hard to synchronize a whole remote directory and its sub-directories just via ftp.exe and a bunch of batch file commands like FOR. In addition, this may impose dependency to external tools in the server.

In the second way, running .Net classes and methods, we have to create our own ftp utility or use third party tools like ftp.exe or MSBuild Community Tasks. In addition this causes using intensive usage of TF Build activities that’s not easy to copy to new Team Foundation builds in new projects.

Third and last way, creating your own activity is harder to implement but has many advantages over other ways including:

1. High flexibility because this is entirely written by yourself.

2. Maintaining is easier because all of your work is kept in a single Visual Studio project.

3. It is easier to deploy it in new team builds because it is simply just one single workflow activity.

4. It is easier to configure. You configure it via its arguments and variables. No need to modify template process itself.

Each TPC needs a separate Build Controller

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.

See also:
My question in StackOverflow
Related content in TFS forum
Related content in GeeksWithBlogs
Jim Lamb’s hack for the problem

Continuous Integration with TFS

It’s a few months that I am dealing with continuous integration, automatic builds, TFS and Team Foundation Build deeply. Experiences during this period learned me some points that I’m glad to share with all:

1. Don’t assume anything about build agent. Specifically don’t assume any library is installed on the agent, any assembly registered in build agent’s GAC, any specific file/folder structure exists in build agent, etc. Otherwise you may encounter build breaks in other agents or at another time. Best practices here is to assume that build agent has just .Net framework installed on it and nothing more.

2. Always add assembly references from source control maintained dlls in same project and just as relative path not as absolute path. Otherwise you may encounter build breaks.

3. Never ever let anyone direct access to live machine that is dedicated to install continuous integration results instantly, specifically for web application projects. Because someone may manually add/modify a file/folder in the web application path. So you may end with a software that needs manual modifications that are never documented nor automated.

4. Automate database creation. Either via maintaining database creation scripts in source control or with help of ORM’s database auto generating feature.