پول ویندوز را بدهیم یا ندهیم؟

مدت‌هاست که می‌خواهم تکلیف خودم را با مجموعه محصولات مایکروسافت و دات‌نت مشخص کنم. یا باید اخلاق را بدون داشتن هیچ دلیل محکمی زیر پا بگذارم و بی‌خیال همه چیز از تمام محصولات مایکروسافت استفاده کنم. یا باید به لینوکس و ابزارهای توسعه‌ای مثل مونو سویچ کنم. یا هزینه‌های احتمالاً خیلی سنگین خرید ویندوز، ویژوال استودیو و غیره را پرداخت کرده و در دنیای ویندوز باقی بمانم.

قبل از ادامه باید به دو نکته توجه کرد. یکی این که موضوع انتخاب بین ویندوز و لینوکس یا بحث‌های open source و غیره نیست. من ویندوز را دوست دارم و می‌خواهم روی آن ادامه دهم. مشکل در اینجا فقط گران بودن و مشکلات تحریم است. نکته دوم این که همه این بحث‌ها وقتی که شما انفرادی کار می‌کنید خیلی اهمیتی ندارد. چون اکثر laptopها شامل یک ویندوز اصلی هم هستند و اگر صاحب آن برنامه‌نویس ویژوال استودیو نباشد، بدون نیاز به هزینه زیادی، Copyright را رعایت کرده است. بحث بر شرکت‌های کوچک و متوسطی است که می‌خواهند به نوعی این مشکل را حل کنند.

راه اول: کنار گذاشتن اخلاق و استفاده غیر قانونی از محصولات مایکروسافت

تا زمانی که دلیل محکمی برای عدم رعایت کپی‌رایت وجود نداشته باشد نباید این کار را کرد. به قول معروف آنچه برای خود نمی‌پسندی برای دیگران هم نپسند. اگر دوست ندارید محصولات نرم‌افزاری شرکت شما حاصل سرمایه‌گذاری و تلاش فراوانی است بدون پرداخت هزینه استفاده شود پس خود شما هم نباید این کار را با محصولات دیگران انجام دهید.

راه دوم: سویچ به لینوکس و ابزارهای توسعه‌ای مثل مونو:
اگر کمی عقلانی فکر کنیم هزینه‌های این راه خیلی خیلی زیاد است. باید سال‌ها تجربه و آشنایی با محصولات مایکروسافت و ویژوال استودیو را کنار گذاشت. علاوه بر این مشتری‌های ما ویندوزی هستند. توسعه نرم‌افزارهایی تحت ویندوز داخل محیط لینوکس کار خیلی سختی است. ضمناً فراموش نکنید که شما یک شرکت هستید که چندین برنامه‌نویس در آن مشغول به کارند. اگر به لینوکس مهاجرت کنید هم باید برنامه‌نویس‌های فعلی را متقاعد کنید که به لینوکس سویچ کنند و هم  این که در استخدام‌های بعدی باید به دنبال معدود برنامه‌نویسانی باشید که بتوانند در محیط شما کار کنند. مثلاً مونو کار باشند.

راه سوم: پرداخت کامل هزینه لایسنس ویندوز و بقیه محصولات:
اول باید ببینیم هزینه استفاده از محصولات قانونی چقدر است و آیا از عهده ما بر می‌آید یا نه. از آنجا که خیلی از شرکت‌ها و برنامه‌نویس‌ها از تمام امکانات محصولات مایکروسافت استفاده نمی‌کنند و از آنجا که فعلاً می‌خواهیم با کمی صرفه جویی کارمان را شروع کنیم، از هزینه خرید ویندوز سرور چشم پوشی کرده و به جای آن از ویندوز ۷ استفاده می‌کنیم. در مورد Visual Studio و MS SQL هم سعی می‌کنیم کارمان را با نسخه‌های express یا محصولات رایگان دیگر مثل MySql یا SharpDevelop راه بیندازیم. پس تنها چیزی که ما می‌خواهیم خرید چند نسخه ویندوز است. فرض کنید شرکتی ۱۰ کارمند دارد و ۱۲ تا کامپیوتر. اگر قیمت هر نسخه از ویندوز (یک ویرایش متوسط) را ۱۵۰ هزار تومان فرض کنیم، پول لایسنس‌هایمان یک میلیون و هشت صد هزار تومان می‌شود. اگر این هزینه را با دیگر هزینه‌های شرکت‌داری مثل اجاره دفتر که ممکن است تا چند میلیون تومان در ماه برسد مقایسه کنیم، خواهیم دید که پرداخت این مبلغ آنقدر سخت نیست که بخواهیم به خاطر آن به لینوکس مهاجرت کرده یا از زیر آن در برویم. البته طرح‌های رایگانی مثل BizSpark هم هستند ولی نمی‌شود در ایران از آنها استفاده کرد.

به این نکته توجه کنید که بعضی از دوستان اظهار می‌دارند که آنها می‌توانند و دوست دارند هزینه ویندوز را پرداخت نمایند اما مایکروسافت اسم ایران را از لیست کشورهایش حذف کرده. علاوه بر این حتی اگر این پول را به نحوی پرداخت کنیم ممکن است به خاطر تحت تحریم بودن نتوانیم از هیچ کدام از حمایت‌ها و امکانات حاصله از خرید قانونی استفاده کنیم. نمی‌دانم صحت و سقم این صحبت‌ها چقدر است. ولی اگر درست باشد متاسفانه می‌تواند دلیل محکمی برای ادامه راه حل غیر اخلاقی شماره یک و بی‌خیال CopyRight شدن باشد.

‫‫آموزش دات‌نت در ویژوال استودیو با ابزار کمکی Feature Builder

حتماً تا حالا ویدئوهای آموزشی مربوط به دات‌نت را دیده‌اید. در این طور ویدئوها یک نفر ماوس و صفحه کلید را به دست گرفته و شروع به ساخت یک پروژه مثل ASP.NET یا WCF کرده و قدم  به قدم تمامی مراحل را در ویژوال استودیو طی کرده و همه را توضیح می‌دهد.

آیا دوست داشتید آن یک نفر کنار شما بوده و همه مراحل را یکی یکی توضیح داده و خود شما مراحل را جلو ببرید؟ هر جا هم که در تایپ یک نمونه کد یا اجرای commandهای ویژوال استودیو مشکل پیدا کردید به شما کمک کرده و مشکل را برطرف نماید؟

اگر جواب مثبت است نگاهی به این نمونه که برای آموزش مقدمات Workflow Foundation است بیندازید. این نمونه آموزشی که با Feature Builder Power Tools ساخته شده، به شما کمک می‌کند تا گام به گام مقدمات WF را یاد بگیرید. نمونه مورد بحث از دو قسمت Guidance Workflow Explorer و Guidance Browser تشکیل شده است. شما از طریق Explorer کلیه مراحل را می‌بینید و از طریق Browser توضیحات هر مرحله را. جالب است بدانید که لینک‌های نمایش داده در Browser به commandّهای خود ویژوال استودیو وصل هستند. یعنی ممکن است با کلیک روی یک لینک، پروژه شروع به اجرا کند یا یک فایل جدید به پروژه اضافه شود. این ابزار آموشی به صورت یک add-in در ویژوال استودیو نصب می‌شود.

اگر شما هم مایلید برای آموزش برنامه‌نویسی از طریق ویژوال استودیو از Feature Builder Power Tools استفاده کنید نگاهی به اینجا و اینجا بیندازید. ساختن یک نمونه آموزشی با این ابزار چندان سخت نیست. فقط کافی است مستندات را به صورت فایل mht (شبیه html) تهیه کرده و با کمک UML Activity Diagram آنها را تبدیل به یک نمونه آموزشی مفید نمایید.

Converting an ASP.NET website to web application project in Visual Studio 2010

During converting a large ASP.NET website (more than 500 aspx page and 750 ascx user control) to a Web Application Project in Visual Studio 2010, I encountered many problems and found solutions for them. I’d like to share them with all.

1. Website does not have namespace in projects. While Webproject does have. It’s better to add namespace for all pages and user controls. Namespaces must match physical path of file in the project tree. If you have not enough time to do it for all items you can just find items with same name and change class names only for them. I have added “Page” in the end of class names of pages that were residing in Pages folder.

2. App_code does work. Better to renamed it to something unreserved like WebCode. Check if build action is set to “compile” not to “content”.

3. Take special care for class name of master files.

4. You need to select “convert to web application” by right clicking the web project. It will add designer file for all items. This process is very slow.

5. rdlc reports files (MS SQL Reporting Services client reports) may produce many problems. web.config and other locations must be corrected with newer versions of Reporting Services.

6. Some datasets must be corrected via editing web project csproj file correctly. You must add an entry like following for designer file too.

     

True
True
DataSet1.xsd

You can also add a dummy dataset to project and see how it is.

7. Consider having all user controls in the project. In my special case “common” folder added to project too.

8. If you encounter errors like “Element ‘x’ is not a known element” in Visual Studio 2010  you may try this solution.

9. You may need additional tricks. For example create a dummy user control and drag it on the page.

10. Seems all user controls must have namespace

11. Total process may need many tricks. So turn on your innovation!

‫clientها و ابزارهای کار با git در ویندوز

mysysgit
خود git است که به صورت command line کار می‌کند.

Cygwin
اجرای git از طریق Cygwin که یک شبیه ساز برنامه‌های لینوکس در ویندوز است.

gitk و git-gui دو ابزار گرافیکی که همراه با خود git نصب می‌شوند.

TortoiseGit
با ویندوز یکی می‌شود. مشابه TortoiseSVN. ظاهراً امکانات خوبی دارد و برای کسانی که به TortoiseSVN عادت دارند خیلی مناسب است.

Git-Cheetah
با ویندوز یکی می‌شود. البته نسبت ویندوزی بودن آن اصلاً مطمئن نیستم.

Git Extensions
با ویندوز یکی می‌شود. به صورت Add-on به ویژوال استودیو هم اضافه می‌شود. ولی Add-on ویژوال استودیو آن اصلاً جالب نیست. تنها کلاینتی است (به جز command line) که تا کنون با آن کار کرده‌ام.

Git Source Control Provider
این برنامه صرفاً یک Visual Studio plugin است. به نظر می‌رسد امکانات خوبی داشته و جای خالی AnkhSVN را بتواند پر کند.

SmartGit
صرفاً یک برنامه ویندوزی کار با git بدون integration با ویندوز یا Visual Studio بوده و ضمناً غیر رایگان است.

GitForce
مشابه SmartGit صرفاً یک برنامه ویندوزی کار با git بدون integration با ویندوز یا ویژوال استودیو بوده ولی رایگان می‌باشد.

Git#‎
API کار با git در C#‎.

اطلاعات بیشتر:

‫مشاهده لاگ NHibernate در Visual Studio

اگر پنجره Output را در ویژوال استودیو به هنگام Debug باز کرده و Show output from را برابر Debug قرار داده باشید می‌بینید که ویژوال استودیو خیلی از فعالیت‌های داخلی برنامه را از جمله Load اسمبلی‌ها یا Exceptionهای برنامه را مدام در آنجا فهرست می‌کند. همین کار را در مورد فعالیت‌های داخلی NHibernate هم می‌توان انجام داد.

NHibernate به طور داخلی از log4net برای log فعالیت‌های داخلی خودش استفاده می‌کند. NHibernate تقریباً تمام کارهایش را log می‌کند. به همین دلیل با دنبال کردن این logها هم می‌توان به بسیاری از اشکالات و ایرادات برنامه‌های مختلف پی برد و هم می‌توان مقدار زیادی از مکانیزم داخلی NHibernate را یاد گرفت. روال معمول برای مشاهده این log ریختن آن در یک فایل text و بررسی آن می‌باشد. اما راه ساده‌تر و موثرتری هم وجود دارد. آن هم این است که به log4net بگوییم خروجی log را به جای فایل text به پنجره Output ویژوال استودیو کپی کند.

برای انجام این کار کافی است بعد از معرفی log4net در web.config یا app.config، خطوط زیر را هم اضافه کنید:



type="log4net.Appender.TraceAppender, log4net">











بعد از انجام این کار بایستی در ابتدای شروع به کار برنامه، log4net را هم با عبارت log4net.Config.XmlConfigurator.Configure();‎ مقدار دهی (initialize) کنید.

البته غیر از این یک راه دیگر هم وجود دارد. در راه دوم یک فایل مستقل برای log4net در نظر گرفته می‌شود به اسم log4net.config. خطوط بالا در این فایل کپی شده (خط اول فایل‌های xml فراموش نشود) و سپس برای راه اندازی اولیه log4net به جای روش قبلی از XmlConfigurator.Configure(new FileInfo(“log4net.config”));‎ استفاده می‌شود.

منبع:
فصل دوم کتاب NHibernate 3.0 Cookbook

‫‫معرفی کتاب ALM with Visual Studio 2010

کتاب Professional Application Lifecycle Management with Visual Studio 2010 راجع به فازهای مختلف توسعه‌ی نرم‌افزار با استفاده از ویژوال استودیو ۲۰۱۰ و TFS صحبت می‌کند. فازهای مختلف توسعه‌ی نرم‌افزار که اصطلاحاً Application Lifecycle Management یا ALM نامیده می‌شود عبارت است از مراحلی که که از تحلیل و درک سیستم شروع شده، با مراحل طراحی، پیاده‌سازی و تست ادامه پیدا کرده و تا مرحله استقرار ادامه پیدا می‌کند. دیگر موارد مورد نیاز از جمله متودولوژی، سورس کنترل، مدیریت پروژه و… نیز جزیی از ALM هستند.

مجموعه Visual Studio 2010 و TFS 2010 با کمک هم، همه‌ی این مراحل را پوشش می‌دهند. یعنی شما با کمک این دو تا هم می‌توانید نمودارهای مختلف UML را که برای بخش‌های مختلف تحلیل و طراحی مورد نیاز هستند را تهیه کنید، هم مراحل کد نویسی، پیاده‌سازی و انواع تست را طی کنید و هم تمام نیازهای Source Control، مدیریت پروژه و… را انجام دهید.

کتاب به پنج بخش اصلی و هر بخش به چند فصل تقسیم می‌شود.

بخش اول: معماری
معرفی امکانات Visual Studio 2010 برای تحلیل و طراحی سیستم. این بخش شامل توضیحاتی راجع به تحلیل، طراحی، معماری نرم‌افزار و مفاهیم مرتبط در UML بوده و به شما نشان می‌دهد چطور می‌توانید با استفاده از Visual Studio 2010 انواع و اقسام نمودارهای UML را تهیه کنید.

بخش دوم: برنامه‌نویس‌ها
معرفی خود ویژوال استودیو و امکانات مختلف آن برای برنامه‌نویسان از جمله: Code Analysis، Code Metrics، Profiling، IntelliTrace و کمی Unit Test.

بخش سوم: تست
معرفی انواع و اقسام تست از جمله Load Test، Web Performance، Manual Test، Coded UI Test و معرفی Lab Management.

بخش چهارم: TFS
معرفی معماری TFS و نحوه‌ی کار با Version Control و Build Engine آن.

بخش پنجم: مدیریت پروژه
معرفی امکانات مدیریت پروژه، استفاده از متودولوژی‌های و گزارشات مرتبط که همگی از طریق TFS مهیا شده‌اند.

آیا خواندن این کتاب مفید بود؟

در ابتدای هر فصل مفهومی که قرار بوده با ویژوال استودیو پیاده‌سازی توضیح داده شده. این مفاهیم به نظر من خیلی مفید بوده‌اند. بخش چهارم که مربوط به TFS بود با توجه به این که منابع چندانی در مورد TFS و خصوصاً TFS 2010 موجود نیستند هم خیلی مفید بوده است. کلیت کتاب دید خیلی خوبی به دست می‌دهد برای آن که بفهمیم منظور از ALM به طور دقیق‌تر چیست. مفیدترین روش استفاده از این کتاب استفاده از آن به عنوان یک کتاب مرجع است. یعنی باید یک دور کتاب را با دور تند خوانده و متوجه شوید که هر قسمت آن راجع به چه موضوعی صحبت می‌کند. سپس صرفاً قسمت‌های مورد نیازتان را به طور کامل خوانده و دیگر قسمت‌ها را بعداً وقتی بخوانید که واقعاً به آن نیاز دارید.

من در خواندن این کتاب متوجه دو موضوع آزار دهنده شدم. اول این که کتاب کار با خیلی از ابزارها و امکانات Visual Studio و TFS را زیادی مفصل توضیح داده. در خیلی از موارد صرفاً با مراجعه عملی به ابزار مربوطه و خواندن مقدار خیلی مختصری راهنما می‌توان از امکانات آن به طور کامل استفاده کرد. دوم این که تقریباً تمام صفحات کتاب پر است از تبلیغات تجاری برای مایکروسافت. یعنی هر وقت قرار است چیزی توضیح داده شود کلی از آن تعریف شده و امکانات آن با رنگ و لعاب خیلی زیادی بزرگ نمایی شده است.

‫Static Code Analysis در Visual Studio

حتماً تا حالا دیده‌اید که هر وقت پروژه‌ای را در ویژوال استودیو Build می‌کنید در کنار فهرست Errorها، فهرستی از Warningها هم نمایش داده می‌شود. این Warningها مواردی هستند که کامپایلر C#‎ تشخیص داده و برای بررسی بیشتر به شما اعلام می‌کند. این Warningها شامل مسائلی ساده و معمولی هستند مثل: یک return وسط متود که نشان می‌دهد کدهای بعد از return هیچ وقت اجرا نمی‌شوند، معرفی یک متغیر و عدم استفاده از آن، مقایسه متغیری از نوع int با null و…

هر چند که خیلی از برنامه‌نویسان به همین Warningها هم هیچ توجهی نمی‌کنند ولی اگر بخواهید کنترل کیفیتی بالاتر از این هم داشته باشید می‌توانید از ابزارهای Static Code Analysis استفاده کنید. ابزارهای مختلفی برای این کار موجود هستند یکی از این ابزارها FxCop نام دارد. FxCop محصول رایگانی از مایکروسافت است که هم به طور مستقل قابل اجراست و هم این که با ویژوال استودیو Integrate است. این ابزار قواعد بسیار مختلفی را چک می‌کند از جمله قواعد نامگذاری، مسائل مربوط به امنیت، Performance و… مواردی که توسط FxCop پیدا می‌شوند به شکل Warning به هنگام Build پروژه‌ها نمایش داده می‌شود.

فعال‌سازی Static Code Analysis بسیار راحت است. کافی است روی نام پروژه راست کلیک کرده و گزینه Properties را زده و به بخش Code Analysis بروید. در آنجا گزینه‌ی Enable Code Analysis را تیک زده و مجموعه Ruleها مورد نظر را مشخص فرمایید. اسم Ruleها گویاست و نشان می‌دهد که چه کاری انجام می‌دهند. برای دیدن فهرست کامل Ruleها به اینجا بروید.

Web Development Server and IIS

I am using “ASP.NET Development Server” with Visual Studio 2010 Ultimate x64 on a Windows Server 2008 R2 x64 machine. Development Server is my primary development and debug my ASP.NET applications. After my work is done, the website moves to an IIS 7.5 on a Windows Server 2008 R2 x64 (same machine) with “DefaultAppPool”.

I was used to think that an application’s behavior is as same as in both “ASP.NET Development Server” and “IIS”. Both recently realized they are not as same as I think. I found 3 situations that they behave differently:

1. Server.MapPath behaved differently between them. Path that returned from one was different from other one. More detail available here.

2. Object comparison in LINQ-to-Object queries with comparing only objects themselves is not possible in IIS, this comparison should be done with comparing object’s Ids.

3. Our data access layer is implemented via Castle ActiveRecord. In an arbitrary method properties of an entity was updating without calling its .Save() method. Despite I agree this is a bug itself, the method was working properly in ASP.NET Development Server but was not working in IIS.

I’m not the only person that think ASP.NET Development Server and IIS behaves differently. Other people like this think like me.

At this moment I’m curios about How Application Pool affects IIS and what is Application Pool of ASP.NET Development Server. Additionally Pipeline mode may be a cause of many of this problems. Pipeline mode in IIS 6 and below was classic that means they was using ISAPI but in IIS 7 and above a new Pipeline has been emerged. This new Pipeline is named “Integrated” and do not use ISAPI.

‫‫‫‫داستان بی‌سوادی ما – ۴: Visual Studio Debugging

یکی از جاهایی که کار می‌کردم دو تا Solution خیلی بزرگ داشتیم. اولی که ۶۴ تا پروژه‌ی ویژوال استودیو بود که همگی تبدیل به dll می‌شدند و دومی که یک پروژه‌ی وب حجیم بود با چیزی بالای ۶۰۰ صفحه aspx. بعضی وقت‌ها که ایرادی پیش می‌آمد مجبور می‌شدم Solution اول را روی کامپیوتر خودم Build کنم، dllهایش را به Solution دوم اضافه کنم، Solution دوم را در حالت Debug بالا بیاورم، آن صفحه‌ای را که مشکل را داشت را باز کنم، روی آن خطی که dllهای Solution اول را صدا می‌زد Break Point بگذارم و هر وقت که اجرای برنامه به آن خط می‌رسید آنقدر F11 می‌زدم و از کلاس‌ها و متودهای مختلف رد می‌شدم تا به آنجایی که تازه می‌خواستم وجود یا عدم وجود ایراد را بررسی کنم برسم. این پروسه خودش در بهترین حالت ۲۰ دقیقه طول می‌کشید تازه بعضی وقت‌ها علت خطا را پیدا کرده و درست می‌کردم و می‌خواستم دوباره آن را امتحان کنم، این خودش یعنی ۲۰ دقیقه‌ی دیگر. حالا خودتان حساب کنید بعضی روزها که می‌افتادیم روی دنده‌ی Debug، چقدر باید وقتمان تلف می‌شد.

چند بار سعی کرده بودم این پروسه را با فراخوانی dllها در یک برنامه‌ی ویندوزی آزمایشی، حذف موقتی بعضی صفحات کم استفاده‌ی Solution دوم، استفاده از Unit Test، استفاده از logging و… کوتاه‌تر و بهینه‌تر کنم اما چندان موفق نبودم. چون به هر صورت بعضی چیزها را فقط در خود پروژه‌ی وب می‌توانستم Debug کنم. متاسفانه این بعضی چیزها خیلی کم تعداد نبودند و همیشه روی اعصاب من و بقیه راه می‌رفتند تا آنجا که بعضی وقت‌ها درخواست‌های Debug یک بخش را کلاً بی‌خیال شده و آن بخش را مجدداً بازنویسی می‌کردم یا این که ایرادهایی را که می‌دانستم قطعاً وجود دارند را مدام پشت گوش می‌انداختم چون واقعاً اعصاب و وقت دیباگ همچون پروژه‌ی حجیمی را نداشتم.

البته تا اینجای کار فقط یک حالت مشکل را شنیدید. حالت دیگر آن وقتی است که امکان استفاده از Break Point را ندارید و اصلاً نمی‌توانید Debug کنید. مثل وقتی که یک عملیاتی از قبیل Data Binding یا به روز رسانی اطلاعات از طریق کدهای Markup یا Declarative صفحات aspx انجام می‌شود.

این مشکلات چند سال است که گریبان‌گیر من است و من دیگر وجود آن را قبول کرده بودم تا این چند وقت پیش با یک ور رفتن کوچولو با StackOverflow فهمیدم که چقدر تا حالا وقتم بیهوده تلف می‌شده است. چون می‌توانستم به راحتی آب خوردن از گزینه Attach to Process ویژوال استودیو برای این کار استفاده کنم بدون آن که این همه وقتم تلف شود.

روش کار بدین صورت است که اول آن Solution وبی را باز می‌کنید و بدون حالت Debug به اجرا در می‌آورید. بعد Solution حاوی dllها را باز کرده و مطمئن شوید که به غیر از فایل‌های dll، فایل‌های pdb را هم دارید. البته اگر ندارید نگران نباشید. این فایل‌ها با یک بار Build به طور خودکار ساخته می‌شوند. قدم بعدی انتخاب گزینه‌ی Attach to Process از منوی Debug ویژوال استودیویی است که Solution حاوی dllها در آن باز است. حالا از فهرست پیش رو، process مربوط به ASP.NET Web Development Server را که معمولاً اسمش با WebDev شروع می‌شود را انتخاب نمایید. در این لحظه ویژوال استودیو خود به خود به حالت Debug می‌رود. شما می‌توانید هر جا که خواستید Break Point بگذارید. اگر به آن صفحه‌ای که نهایتاً آن کد را اجرا می‌کند بروید، می‌بینید که ویژوال استودیوی حاوی dll در محل Break Point انتخابی شما آماده دریافت F10 و F11 است. به همین سادگی! این کار حتی در مورد کدهایی هم که به طور مستقیم از markup صدا زده می‌شوند نیز قابل انجام است.

به عنوان سورپریز این قضیه را داشته باشید که می‌توانید عین همین کار را بدون اجرا کردن پروژه‌ی وبی از طریق ویژوال استودیوی اول هم انجام دهید البته به شرطی که همان پروژه را در IIS کامپیوترتان داشته باشید. روش کار به این صورت است که در بخش Attach to Process به جای Web Development Server از process مربوط به IIS که اسمش در ویندوز دو هزار و هشت w3wp است استفاده کنید.

سورپریز دومی هم وجود دارد. می‌توانید به جای استفاده از IIS کامپیوتر خودتان از IIS دیگر کامپیوترها هم استفاده کنید. یعنی می‌توانید از طریق ویژوال استودیوی کامپیوتر خودتان Web Applicationهایی که در IIS یک کامپیوتر دیگر نصب هستند را Debug کنید. اسم این کار Remote Debugging است.

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.