کاری که من انجام می‌دم، Refactor یک فرم به یک PartialView است و سپس استفاده از این PartialView که با یک ViewModel کار می‌کند، در چندین و چندجا.

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

تکرار نیست. هر View ساختار مستقل خودش رو داره. به نظر استفاده از یک مدل کلی برای چندین View حجم کدنویسی کمتری داره ولی واقعیت این است که مدام باید یک سری فیلدها را exclude کنید تا به مشکل امنیتی برنخورید.
در کل انجام کار اصولی الزاما به معنای کمتر کدنوشتن نیست. ضمن اینکه کتابخانه auto-mapper کار نگاشت viewmodel به model رو می‌تونه خیلی ساده انجام بده. بنابراین حداقل در این قسمت حجم کدنویسی کمی خواهید داشت.

فقط قسمت Database.SetInitializer را نال کنید تا برنامه مستقیما کار به روز رسانی ساختار بانک اطلاعاتی را انجام ندهد. بعد، از اسکریپت تولیدی مطابق روشی که در انتهای بحث توضیح دادم پس از بررسی‌های لازم استفاده کنید. بنابراین تنظیمی را لازم نیست حذف کنید. فقط باید با احتیاط جلو رفت و بررسی کامل اسکریپت تولیدی و سپس اجرای دستی آن روی بانک اطلاعاتی.

به شخصه برای تمام Viewهایی که درست می‌کنم از ViewModel استفاده می‌کنم و نام آن‌ها را هم نام view مورد نظر + کلمه ViewModel درنظر می‌گیرم.
به هیچ عنوان هم از یک مدل (domain model) به عنوان مدل یک View استفاده نمی‌کنم خصوصا به دلایل امنیتی که نباید کل model را در معرض دید قرار داد. برای مثال اگر یک صفحه فقط به نام کاربری و پسورد نیاز دارد، این view به یک viewmodel به نام UserInfoViewModel با دو فیلد یاد شده نیاز دارد و نه بیشتر.
به طور خلاصه برای مثال اگر از EF Code first استفاده می‌کنید، کلاس‌های مدل آن نباید مستقیما در MVC استفاده شوند. این M در MVC به معنای مدلی مخصوص View است و نه کلاس‌های اصلی دومین شما.

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

- با debug=false هم انجام میشه. برنامه رو خارج از ویژوال استودیو اجرا کنید. بحث دیباگ کد در VS.NET با مدیریت خطا توسط ASP.NET متفاوت است. debug=false برنامه ASP.NET رو تبدیل به حالت Release می‌کنه اما به این معنا نیست که مکانیزم‌های ASP.NET رو کلا از کار می‌اندازه. مصرف حافظه برنامه کمتر میشه. debug symbols از اسمبلی نهایی حذف خواهند شد. کامپایلر روی کد نهایی بهینه سازی‌هایی در جهت بالابردن سرعت انجام می‌ده.
- در MVC اگر از فیلتر Handle Error استفاده بشه application_error فراخوانی نخواهد شد. به علاوه با وجود ELMAH ضرورتی به استفاده از Handle error و application_error نیست. توضیح دادم در متن فوق. 
ضمن اینکه دیباگ کار شخصی افراد نیاز به بودن پروژه آن‌ها و بررسی آن(ها در یک انجمن مرتبط یا توسط یک مشاور) دارد. این جملات مبهم و کلی «من یه کاری یه جایی کردم، یکی یه چیزی گفت، برای من کار نکرد» ارزش یا امکان بررسی ندارند.
- custom errors قرار گرفته در ریشه سایت بر روی کل سایت اعمال می‌شود (و تمام برنامه‌هایی که در زیر پوشه‌های آن هستند). در فایل‌های کانفیگ ASP.NET مباحث ارث بری وجود دارند. برای لغو آن یکی از راه‌ها استفاده از تگ location است، مثلا:

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

در متن توضیح دادم:
البته TempData یک سری تفاوت هم با سشن معمولی ASP.NET دارد:
- بلافاصله پس از خوانده شدن، حذف خواهد شد.
و ...

به این منو مراجعه کنید: Tools/Import and Export Settings