یک نکته‌ی تکمیلی
روشی که در سری ابتدایی Angular مطرح شد‌ه‌است، مبتنی بر سیستم مدیریت ماژول‌های system.js هست. اما در نهایت روش توصیه شده‌ی توسط تیم Angular استفاده از Angular CLI است که مبتنی بر webpack است. این روش بسیار ساده‌تر (کار با ابزاری استاندارد)، ساخت‌یافته‌تر (به همراه تنظیماتی مبتنی بر best practices)، بهینه‌تر (به همراه بهینه سازی‌های بسیاری جهت کاهش حجم نهایی و کاهش تعداد فایل‌های تولیدی) و پیشرفته‌تر از روش system.js هست و توضیحات تکمیلی آن در مطلب « Angular CLI - قسمت پنجم - ساخت و توزیع برنامه» ارائه شده‌اند. این روشی است که برای ارائه‌ی نهایی از آن استفاده می‌شود و در مطالبی مانند «یکپارچه سازی Angular CLI و ASP.NET Core در VS 2017» و «سفارشی سازی صفحه‌ی اول برنامه‌های Angular CLI توسط ASP.NET Core» از آن‌ها استفاده شده‌است.   

در روش هایی که اشاره کردید مدیریت ورژن‌ها در داخل یک نسخه از برنامه انجام شده. که در این حالت هر دو ورژن رو از طریق یک ریلیز ارائه میکنید که در هر صورت امکان مختل شدن هر کدوم وجود داره. یعنی برای اصلاح نسخه1، نسخه2 هم مجدد پابلیش می‌شود.

- گزینه‌ی «"uncheck “Verify that file exists» را هم امتحان کنید.
- این سؤال خارج از بحث است. بازگرداندن View هیچ ارتباطی به مسیریابی ندارد. فقط کافی است بنویسید:
تولید URLهای خودکار بر اساس اطلاعات مسیریابی در Viewهای برنامه، توسط متدهای توکار ActionLink و امثال آن انجام می‌شود.
- تمام خطاهای مدیریت نشده‌ی برنامه‌های وب در لاگ ویندوز ثبت می‌شوند. آن‌ها را بررسی کنید. همچنین ELMAH را هم نصب کنید تا خطاها را برای بررسی بیشتر لاگ کند.
- روش‌های قدیمی را با MVC کار نکنید. صفحه‌ی اول سایت، همان صفحه‌ای است که در مسیریابی پیش فرض تعریف شده‌است. یعنی همان اکشن متد Index در کنترلر Home، به همراه View ایی که مد نظر شما است.

- همه شاید از الگوی واحد کار استفاده نکنند.
- کسانی هم که از الگوی واحد کار استفاده می‌کنند شاید بد نباشد بررسی کنند که در پایان کار Context و Connection زنده‌ای هنوز وجود دارد یا خیر.
- همه جا امکان استفاده از الگوی واحد کاری که از یک Context در طول یک درخواست استفاده می‌کند، نیست. خصوصا در مکان‌هایی که وهله سازی آن‌ها را نمی‌توان تحت کنترل خودکار IoC Containerها در آورد؛ مثلا در یک Role Provider که راسا توسط ASP.NET وهله سازی می‌شود و یا یک وظیفه‌ی فعال پس زمینه.
- گزارشی که در انتهای کار روش فوق تهیه می‌شود، مستقل است از نحوه‌ی بکارگیری و مدیریت وهله‌های Context. همچنین مستقل است از Code-first یا Db first و غیره. قابلیت interceptor آن، بحثی است عمومی.
- «هدف مقاله فعلی پیدا کردن وهله‌های dispose نشده درون متدهای برنامه است»
نهایتا از هر روشی که استفاده کنید، در متدی مشخص، وهله سازی می‌شود و شاید در جایی Dispose و یا خیر. در اینجا می‌شود از این نوع مکان‌ها گزارش گرفت.

- «پیش آمدن همزمانی در اجرای وظایف»
خاصیت Order را برای وظایفی که قرار است در یک زمان مشخص اجرا شوند، مقدار دهی کنید. 1و 2 و 3 و الی آخر.
- «حتی می‌توان از Scheduler خود ویندوز و یا Jon‌های SQL Server هم بهره برد».
بله. به شرطی‌که سرور در اختیار شما باشد و دسترسی کافی برای انجام اینکار را داشته باشید. البته در این حالت خاص، مدیریت آن یکپارچه با یک برنامه‌ی وب نیست.
در سرورهای اشتراکی روش ارائه شده در این مطلب بدون نیاز به سطح دسترسی خاصی کار می‌کند. ضمنا برای ASP.NET نوشته شده است و این قابلیت را دارد که به شما اعلام کند مثلا تا 30 ثانیه دیگر برنامه از سرور unload می‌شود؛ توسط خاصیت IsShuttingDown. همچنین حق تقدم ترد آن طوری تنظیم شده که سبب اختلال در عملیات و عملکرد متداول سایت نشود.
- «آیا توصیه شده برای استفاده در پروژه‌های بزرگ هست؟»
یک به اشتراک گذاری بود از قسمتی از کدهای زیر ساخت سایت جاری که هم اکنون مورد استفاده است (مقدمه بحث).

چندین علت داره:

- پروسه کامپایل کدهای دات نت یک مرحله‌ای نیست. کلا در دات نت کدها به یک زبان میانی به نام IL ترجمه میشن. بعد این IL توسط  JIT compiler تبدیل به کدهای ماشین میشه. در ASP.NET این مساله هم برای کدهای پشت صحنه برنامه و هم برای خود صفحات رخ می‌ده. بنابراین برای بار اول مشاهده، روند این پروسه الزامی هست. ولی برای دفعات بعدی مشاهده خیر. البته روش برای پیش کامپایل کردن کامل صفحات هم وجود داره و یا در IISهای جدید یک سری مبحث warmup توکار پیش بینی شده.

- همچنین IIS برای مدیریت منابع سرور، یک سایت رو مدام در حافظه نگه نمی‌داره. فقط زمانیکه اولین درخواست به سرور میرسه سایت رو بارگذاری می‌کنه و application pool اون رو استارت. این هم یک زمان اولیه اندکی رو ممکنه به خودش اختصاص بده. بعلاوه پس از مدتی، یک سایت بیکار رو از حافظه خارج می‌کنه. بهش می‌گن ریسایکل کردن. در ASP.NET 4.0 به بعد امکان تنظیم auto-start برای سایت‌ها هست.

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

اما اینجا جای تشکر داره از افرادی که "مثلا در سایت StackOverFlow" با مدیریت خودشون (حذف یا ویرایش سوالات) باعث می‌شن که سوالات بی مورد و تکراری کمتر بشن و ما با یک جستجوی ساده بتونیم به جواب برسیم

با سلام؛

سلام،
زمانیکه با ORM هایی از نوع Code First کار می‌کنید مثل NHibernate یا مثل نگارش بعدی Entity framework ، ذهن خودتون رو از وجود جداول حاضر در بانک اطلاعاتی خالی کنید. جدولی به نام CoursesToStudents توسط ساز و کار درونی NHibernate‌ مدیریت خواهد شد و لزومی ندارد برنامه در مورد آن اطلاعاتی داشته باشد.
موردی را که شما نیاز دارید کلاسی است به نام نتایج دوره؛ مثلا چیزی به نام CourseResult . این کلاس ارجاعاتی را به شیء دانشجو و شیء دوره دارد، به همراه نمره نهایی یا مثلا خاصیت قبول شده و برای مثال تاریخ امتحان و خواص دیگری که صلاح می‌دانید.
زمانیکه NHibernate اسکریپت اعمال این نگاشت‌ها را تشکیل دهد (توسط امکانات کلاس SchemaExport که در مطلب بالا ذکر شده)، در جدول نهایی بانک اطلاعاتی شما به ازای ارجاعات به اشیاء یاد شده، یک کلید خارجی خواهید داشت. این کلاس جدید تاثیری روی سایر روابط ندارد.