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.
We have a Visual Studio solution that uses some external assemblies coming from third parties. This solution resides in TFS 2010 version control. We have configured Team Foundation Build to do automatic builds of the solution. As you know you should put any external assemblies in TFS Version Control to do a proper build without any build breaks. So we did same. Whenever we want to update the assembly with a new one, we first check-out the item, copy newer assembly to local folder and then check-in it again.
An assembliy (.dll file) in TFS can not be checked-out by multiple users because it’s a binary file and can’t merged or compared. Just like files of type gif. We had a situation recently that a user checked-out one assembly without checking-in it again or undoing his change. As he went to vacation, that assembly remained locked in TFS version control and no one could check-out that assembly again. Me as TFS administrator was forced to unlock it. So googled for the solution and found Martin Woodward’s work-around:
tf lock $/MyProject/MyPath/MyFile.cs /lock:none /workspacename:WorkSpaceName /server:my_server
Unfortunately this was not working for me because I got error:
Tf10152: the item xxx must remain locked because its file type prevents multiple check-outs.
I was very hopeless but another link showed me how to use “undo” to solve my problem. This time it worked nicely:
tf undo /workspace; /server: item
For those unfamiliar with “tf”, it is powerful command-line tool for TFS that can be run from a “Visual Studio Command Prompt” window.
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
While using TFS 2010 as the only repository of source code and project management repository for a company with more than 10 developer, it is very important to handle backup/restore plans as accurate as possible. As I needed to backup such a TFS server correctly, I have compiled a check list for myself that I’d like to share it with all.
1. DVD of softwares must be kept at a separate reachable place. Including Windows Server 2008 R2, SQL Server 2008, TFS 2010, SharePoint and any original/modified template process like Scrum for Team System version 3’s x64 template process.
2. Know of any good online/offline documentation for backup/restore: Backing up and Restoring Your Deployment. Some good key points of this document are:
-Databases to backup: TFS_Configuration, TFS_Warehouse, TFS_CollectionName (all collections), TFS_Analysis (if any), ReportServer, ReportServerTempDB, WSS_Config (if any), WSS_Content (if any), WSS_AdminContent (if any)
-TFS_Configuration database must be last database to backup and first database to restore.
3. Backup the Reporting Services Encryption Key using “Reposrting Services Configuration Manager”. It’s a tiny file. This file must be protected with a password. Don’t forget to write down the password for future use. Alternatively you can use a simple password like 123 so you never forget it.
4. Use this guidline for: Restore Data to the Same Location and use this for Restore a Single Server Deployment to New Hardware.
5. You can always use a virtual machine to test you backups.