- تا ASP.NET MVC 5 از JavaScriptSerializer در JsonResult استفاده می‌شود.
- در نگارش بعدی ASP.NET MVC که با Web API یکی شده (یعنی در یک کنترلر هم می‌توانید ActionResult داشته باشید و هم خروجی‌های متداول Web API را با هم) اینبار تامین کننده‌ی JsonResult از طریق تزریق وابستگی‌ها تامین می‌شود و می‌تواند هر کتابخانه‌ای که صلاح می‌دانید باشد. البته یک مقدار پیش فرض هم دارد که دقیقا از JSON.NET استفاده می‌کند.

-  نحوه استفاده از افزونه Firebug برای دیباگ برنامه‌های ASP.NET مبتنی بر jQuery 
- محل تعریف اسکریپت‌ها باید در فایل Layout باشد و بهتر است از bundling موجود استفاده کنید.
+ مسیردهی صحیح فایل‌ها در ASP.NET MVC با توجه به مسایل مسیریابی آن باید توسط Url.Content صورت گیرد:
البته Razor نگارش 2 به بعد با روش زیر هم سازگار است:

- فایل‌های استاندارد آن روی Any CPU کامپایل شده‌اند. ادامه در اینجا
+ وابستگی WindowsBase هم یک فایل استاندارد مجموعه دات نت است و نه خارج از آن و در WPF از آن استفاده می‌شود. بنابراین مشکلی ندارد (چون حتی اگر یک dll بومی ویندوز هم باشد، با توجه به اینکه عملا دو نگارش X86 و X64 دات نت وجود دارند، بسته به سیستم مورد استفاده، یکی از آن‌ها به صورت خودکار در ابتدای کار نصب دات نت فریم ورک، نصب خواهد شد).

از چه دیتابیسی استفاده می‌کنید؟ اگر SQL Server است که تا قبل از نگارش 2008 آن چنین اجازه‌ای رو به شما نمی‌ده تا یک فیلد منحصربفرد نال پذیر داشته باشید. اگر 2008 به بعد است، باید ایندکس فیلتر شده برای اینکار تعریف کنید. مثلا:
اطلاعات بیشتر اینجا و اینجا
بر همین مبنا باید قسمت ADD CONSTRAINT متد ExecuteUniqueIndexes را در صورت نیاز بازنویسی کنید.

مطلب فوق در مورد iTextSharp بود.
در PdfReport متد header.CacheHeader وجود دارد که کل هدر را کش می‌کند (حالت پیش فرض است) و اشیاء آن را یکبار محاسبه و به صفحات اضافه خواهد کرد (در آخرین نگارش موجود در SVN). به این ترتیب فرقی نمی‌کند که هدر سفارشی است یا هر نوع پیش فرض دیگری. برای تمام آن‌ها کش توکار اعمال خواهد شد.
اگر خواستید به ازای صفحات مختلف هدرهای مختلفی داشته باشید نیاز است header.CacheHeader را false کنید. در این حالت بهینه سازی صورت نخواهد گرفت.

- پیش فرض حجم مجاز قابل آپلود فایل‌ها در ASP.NET حدود 4 مگ است که کافی نیست. این رو باید بیشتر کنید. همچنین حجم فایل که بالا رفت نیاز است سرور زود timeout نزند.
- خاموش کردن enableVersionHeader و همچنین MvcHandler.DisableMvcResponseHeader سبب می‌شود تا رباط‌های باگ یاب سایت‌ها نتوانند دقیق عمل کنند چون شماره نگارش MVC و ASP.NET مورد استفاده مخفی می‌شود.
- از کوکی استفاده کنید. برای شروع: (^)
در دوران ASP کلاسیک، از سشن عموما برای مشخص سازی وضعیت لاگین افراد استفاده می‌شد. الان با وجود روش‌های مختلف اعتبارسنجی در ASP.NET هیچ ضرورتی به استفاده از آن نیست.

سیستم NHibernate از روز اول آن Code first بوده. EF هم در نگارش آخر آن به این نتیجه رسیده که روش Code first انعطاف پذیری بیشتری داره و دقیقا چیزی هست که برنامه نویس‌ها با آن راحت‌تر هستند.
البته برای NH یک سری ابزار تجاری توسط شرکت‌های ثالث درست شده که طراح دارد ولی ... فکر نمی‌کنم با استقبال مواجه شده باشد چون روش Code first یعنی رها شدن از انبوهی کد که توسط ابزارها نوشته می‌شن و عموما هم بهینه نیستند.

- با توجه به محتوای فایل هست و این محاسبات فقط بر اساس درخواست مرورگر انجام می‌شود. یعنی هربار به ازای نمایش صفحات این کارها و محاسبات صورت نمی‌گیرد و اگر کش شده باشد (که شده برای یکسال)، اصلا فشاری به سرور وارد نمی‌شود چون مرورگر برای موارد کش شده درخواست جدیدی را به سرور ارسال نمی‌کند.
- نگارش تولیدی بر اساس هش محتوای فایل محاسبه می‌شود به صورت خودکار.
- در وب فرم‌ها هم این قابلیت مدتی هست که وجود دارد: (^)

سیلورلایت به طور وسیعی در محصولات سرور مایکروسافت داره استفاده میشه:
https://www.dntips.ir/2011/03/silverlight.html
در نگارش 5، قابلیت PInvoke به آن اضافه شده یعنی دسترسی به Win32 API که علت داشته. علتش هم بر می‌گرده به همین محصولات سرور و نیاز به دسترسی بیشتر.
هرچند این حالت محصول را به ویندوز گره خواهد زد اما ... خوب هدف محصولات سرور هم دقیقا همین است. قرار نیست جای دیگری اجرا شوند.

یک مطلب دیگر رو هم اضافه کنم. ThreadPool در دات نت 4 به 64 logical processors محدود شده. به عبارتی مثلا حین استفاده از Parallel.For/ForEach این محدودیت وجود دارد و پس از آزاد شدن یک task ، task بعدی (پس از 64 البته) وارد عمل خواهد شد و همینطور الی آخر
+
ویندوز سرور 2008 نگارش R2 فقط تا 256 logical processors رو پشتیبانی می‌کنه.