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.

Unlocking TFS Version Control items

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.

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

Backing up TFS 2010

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.

‫سوء تفاهم با WF

WF یا همان Window Workflow Foundation فناوری جدیدی است که مایکروسافت از نسخه 3.0 به دات‌نت اضافه کرده و در نسخه 4.0 حسابی به آن رسیده است. ظاهراً این فناوری برای مایکروسافت خیلی با ارزش است چون سعی دارد این فناوری را مدام توسعه داده و از آن در جاهای مختلف استفاده کند. مثلاً مایکروسافت در TFS 2010 در کنار MSBuild از یک لایه اضافی برای راحت‌تر کردن و توسعه امکانات Team Build استفاده کرده که در این لایه از WF 4.0 استفاده شده.

از اولین باری که اسم Windows Workflow را شنیدم فکر می‌کردم قرار است از این تکنولوژی برای راحت‌تر کردن پیاده‌سازی Workflowهای معمول سازمان‌ها استفاده شود. حتی در شرکت قبلی این نقشه را داشتم که از WF برای پیاده‌سازی Workflow در شرکت مشتری استفاده کنم. اما زهی خیال باطل. چون به تازگی به خاطر نیازی که در Team Build 2010 به Workflow پیدا کردم متوجه شدم WF برای آن کار مناسب نبوده است. برای درک بهتر موضوع می‌توان Workflowها را به دو نوع اداری و برنامه‌ای تقسیم کرد:

Workflow اداری: منظور روش انجام کار در ادارات و سازمان‌هاست. وقتی که شما به یک اداره رفته و درخواستی را به کارمند «الف» ارائه می‌دهید یک Workflow را شروع کرده‌اید. این درخواست مثلاً می‌تواند به کارمند «ب» رفته و همین طور در آن اداره در اثر شرایط و ترتیب معین بین افراد مختلف گردش کرده تا نهایتاً به یک حالت خاص برسد. خیلی از نرم‌افزارهای معمول اداری چنین امکانی را پیاده‌سازی کرده و به کاربر اجازه می‌دهند Workflow دلخواه خودش را تعریف و در سیستم استفاده کند. این نرم‌افزارها معمولاً از هیچ فناوری خیلی خاصی به جز امکانات معمول platform توسعه نرم‌افزار استفاده نمی‌کنند.

WorkFlow برنامه‌ای: Workflow را در سطح یک نرم‌افزار تشریح می‌کند. به عنوان یک مثال خیلی ساده، فرض کنید بخشی از یک نرم‌افزار شامل استخراج رکورد خاصی از اطلاعات، تصمیم گیری بر اساس اطلاعات موجود در آن رکورد، ارسال ایمیل، نمایش پیغام و بعضی کارهای دیگر بر اساس آن تصمیم‌گیری باشد. روال توضیح داده شده در اینجا را می‌توان به صورت یک Workflow چند بخشی بیان کرد.

Windows Workflow Foundation یا WF برای پشتیبانی از Workflow برنامه‌ای ایجاد شده است. WF کمک می‌کند که هر کدام از تکه‌های خیلی بزرگ نرم‌افزار به یک Activity تبدیل شود. این تکه‌ها بعداً در قالب یک Workflow با هم ارتباط پیدا می‌کنند. نهایتاً این Workflow در جایی host شده و توسط WF Runtime شروع به اجرا می‌کند. WF مدعیست به برنامه‌نویسان امکان می‌دهد تا بخش‌ها مختلف Workflow به طور موازی و در کامپیوترهای مختلف به اجرا درآورند. در واقع شعار WF نوشتن برنامه‌های بزرگی است که به راحتی برنامه‌های کوچک قابل توسعه و نگهداری هستند.

اما چرا نمی‌توان یک Workflow اداری را با کمک WF پیاده سازی کرد؟ چون به نظز من یک Workflow اداری اولاً تشکیل شده از قطعاتی از اطلاعات نه قطعاتی از نرم‌افزار، ثانیاً نباید از کاربر اداری توقع داشت برای تعریف Workflow از ویژوال استودیو و XAML استفاده کند، ثالثاً استفاده از WF نیاز به Build مجدد نرم‌افزار دارد که این امکان در محیط کاربر اداری فراهم نیست، رابعاً WF ابزار بیش از حد بزرگی برای انجام این کار است. انجام این کار با WF مثل این است که برای بلند کردن یک دوچرخه معمولی از یک جرثقیل چند ده تنی استفاده شود.