یکی از مواردی که بعضی از همکاران هنگام ارائه برنامه‌های خود رعایت نمی‌کنند، تفاوت قائل نشدن بین حالت release و debug در زمان کامپایل پروژه، برای ارائه نهایی است.
هنگام استفاده از حالت release ، گزینه‌های بهینه سازی کامپایلر فعال شده و همچنین debug symbols از اسمبلی نهایی تولید شده حذف می‌گردد (بنابراین حجم اسمبلی نهایی نیز کمتر خواهد شد). لازم به ذکر است در حالت release ، میزان مصرف حافظه برنامه تولید شده نیز کمتر از حالت debug خواهد بود. گاهی از اوقات سرعت اجرای این دو حالت تا چندین برابر در بعضی از الگوریتم‌ها می‌توانند متفاوت باشند.
مطابق مستندات موجود، وجود debug symbols هیچگونه تاثیری بر روی کارآیی یک برنامه دات نت ندارند.
لازم به ذکر است که عمده بهینه‌سازی‌ها در دات نت توسط JIT compiler صورت می‌گیرد (تا 99 درصد) و نه توسط کامپایلر زبان مورد استفاده (به همین جهت است که عده‌ای اعتقاد دارند در نهایت و هنگام اجرا تفاوتی مابین زبان‌های مختلف دات نت وجود نخواهد داشت). بر روی JIT compiler نیز می‌توان تاثیر گذاشت و نحوه عملکرد آنرا تغییر داد (حتی بر روی یک اسمبلی کامپایل شده). برای مثال یک فایل ini کنار اسمبلی پروژه خود ایجاد کنید (xyz.ini که در اینجا xyz.exe نام فایل اجرایی برنامه است). محتویات این فایل می‌تواند به صورت زیر باشد:
در اینجا می‌توان بهینه سازی را فعال و غیر فعال کرد و یا مطابق تنظیمات فوق برنامه را جهت دیباگ آماده نمود. (این روش با اسمبلی‌های ASP.Net کار نمی‌کند)
در دات نت فریم ورک 2 ، TrackingInfo مربوط به JIT compiler همواره تولید خواهد شد اما می‌توان بر روی بهینه سازی نهایی به صورت فوق نیز تاثیرگذار بود.

نکته:
اگر می‌خواهید هنگام مشاهده گزارش خطا، شماره سطر مورد نظر نیز در کدهای شما گوشزد ‌شود فایلهای pdb - program database تولید شده را هم ارائه دهید. حال شاید بخواهید هم برنامه را در حالت release ارائه دهید و هم pdb آن تولید شود، در این حالت باید خط فرمان کامپایل برنامه، با سوئیچ debug:pdbonly/ اجرا شود.
این مورد را در قسمت خواص پروژه، گزینه build و با کلیک بر روی دکمه advanced نیز می‌توان تنظیم نمود. (حالت پیش فرض release در VS.Net است)

خلاصه‌ی کلام: لطفا هنگام ارائه نهایی، گزینه release را از بالای صفحه در VS.Net انتخاب کنید. با تشکر!

Clean code is C# code that is easy to read and understand, both for the original author and any future developers who may need to work on the codebase. It is a code that follows best coding practices and is organized in a logical way. 

Working as a .NET Professional is a tumultuous rollercoaster ride of emotional highs and crushing lows. It’s likely the same for other communities, with different flavors of success and failures. I have over a decade of .NET development work, and I am here to share some general mantras that have served me well. 

1. Write Unit Test for Non-Public Methods

...

Finalizers are interesting and dangerous because they are an environment in which everything you know is wrong. I’ve written a lot about the perils of C# finalizers / destructors (either name is fine) over the years, but it’s scattered in little bits over the internet. In this series I’m going to try to get everything in one place; here are a bunch of things that many people believe about finalizers, all of which are wrong.

Finalizers are interesting and dangerous because they are an environment in which everything you know is wrong. I’ve written a lot about the perils of C# finalizers / destructors (either name is fine) over the years, but it’s scattered in little bits over the internet. In this series I’m going to try to get everything in one place; here are a bunch of things that many people believe about finalizers, all of which are wrong.