‫سوء تفاهم با 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 مثل این است که برای بلند کردن یک دوچرخه معمولی از یک جرثقیل چند ده تنی استفاده شود.

Versioning assemblies with Team Build 2010

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.