جهت تکمیل بحث در مورد mixed-mode assemblies به این آدرس مراجعه کنید : (+)
به عبارتی اسمبلی‌هایی هستند که حاوی کدهای managed و unmanaged می‌باشند مانند اسمبلی ساخته شده برای SQLite که هم کدهای دات نتی دارند و هم کدهای اصل مرتبط با خود SQLite که با زبان C نوشته شده.

در مورد CHM پیشتر مطلب نوشتم:(+)
برای استفاده از آن در یک برنامه مستقل، تمام این‌کارها از طریق خط فرمان این برنامه (html help workshop) هم قابل انجام است. فقط فایل‌های پروژه و ایندکس و غیره آن‌را برنامه شما باید تولید کرده و به صورت پارامتر خط فرمان به آن ارسال کند.

اگر علاقمند به تهیه خروجی از این گزارش‌ها باشید، کلاس‌های تهیه خروجی PDF/PNG/XPS را اینجا آپلود کردم:
(+)

همچنین اگر مایل باشید که به کنترل DocumentViewer دکمه‌های دلخواه تهیه خروجی را اضافه کنید می‌توان از قالب زیر کمک گرفت:
(+)

این پروژه در حال حاضر دو ایراد داره:
- سر ستون‌های گزارش‌ها در صفحات مختلف تکرار نمی‌شوند.
- امکان گروه بندی ندارد.

مشکل حاد دیگری من ندیدم.

در ادامه ... (+)

مایکروسافت ASP.NET Ajax را با اون عظمت و زحمتی که براش کشیده بودند، در مقابل jQuery بازنده اعلام کرده الان شما صحبت از Anthem.Net می‌کنید که فقط منحصر است به ASP.NET web forms آن هم نگارش‌های قبل از سه آن + پشتیبانی از مرورگرهای مختلف هم در آن ضعیف است.
هدف مایکروسافت از اینکار مدیریت هر دو پروژه MVC و Web forms است آن هم با هزینه کم، کیفیت بالا و سازگار با تمام مرورگرها.
ضمنا این رو در نظر باشید که یکی از توانمندی‌های jQuery، Ajax است (از کار با DOM گرفته تا دستکاری CSS نمایش داده شده، تا Animation ، مدیریت ساده‌تر رخدادها، اعمال قالب به سایت و غیره) و این مورد مزیت مهمی است نسبت به تمام کتابخانه‌هایی که فقط برای یک کار و آن هم سهولت تولید برنامه‌های مبتنی بر Ajax ایجاد شده‌اند و از چند مشکل مهم رنج می‌برند:
- تک کاره‌اند. فقط Ajax .
- مشکل سازگاری با مرورگرهای مختلف را دارند.
- به صورت فعال توسعه داده نمی‌شوند؛ رفع باگ نمی‌شوند و غیره. برای مثال فواصل به روز رسانی همان Anthem.Net را بررسی کنید.
- توسعه پذیر نیستند. برای مثال آیا می‌توان برای Anthem.Net افزونه نوشت؟
- حجم بالایی دارند.
- سرعت پایینی دارند.

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

و RAD هزینه بر است. یعنی چی؟ یعنی حجم بالای کدهای اسکریپتی که باید به برنامه‌ی شما مثلا توسط ASP.NET Ajax تزریق شود که مبادا شما بخواهید دست خودتان را به نوشتن چند سطر کد جاوا اسکریپتی آلوده کنید. همچنین حجم تبادل اطلاعات ASP.NET Ajax را هم که مبتنی است بر RAD را هم با حجم اطلاعات مبادله شده توسط jQuery مقایسه کنید (با پلاگین فایرباگ مربوط به فایرفاکس). این حجم واقعا زیاد است و قابل مقایسه نیست. (تمام این‌ها هزینه‌های RAD است)
ضمنا وجود 100 ها افزونه و پلاگین نوشته شده برای jQuery کار شما را بسیار بسیار ساده می‌کنند، مانند پاسخ قبلی من در این مطلب.
فقط باید کمی وقت بگذارید و چیزی را بیاموزید که واقعا ارزش دارد. گیرم فردا نخواستید با ASP.NET کار کنید. تمام این اطلاعات در PHP هم به درد شما می‌خورد، چون قسمت سمت کلاینت آنچنان تفاوتی نمی‌کند و jQuery یک کتابخانه‌ی سمت کلاینت است.

من در مورد jQuery در این سایت مطلب زیاد منتشر کردم. به عمد هم تمامشون با دید ASP.NET بوده.
به تگ‌های JavaScript و یا ASP.NET در کنار صفحه مراجعه کنید یا کلا فایل CHM خلاصه سایت رو جهت سهولت مطالعه دریافت کنید.
و بله. مایکروسافت اومده تمام این‌ها رو برای شما در ASP.NET Ajax کپسوله و از دید شما مخفی کرده. همین کپسوله سازی در پلاگین‌های jQuery هم با کیفیت بالا موجود است مثلا : (+)

ضمنا یک مورد رو در باره‌ی LINQ to SQL و ASP کلاسیک اضافه کنم. جایگزین شدن entity framework بجای L2S یا ASP.NET به جای ASP کلاسیک، یک روند سالم و سلامت توسعه است. LINQ to SQL فقط محدود است به SQL Server اما الان اکثر بانک‌های اطلاعاتی موجود پروایدر EF دارند و مدل توسعه‌ی آن بسته نیست. ASP کلاسیک رو نمی‌دونم باهاش کار کرده بودید یا نه؟ رسما یک فاجعه بود! مخلوطی از کدهای برنامه داخل کدهای HTML و وابستگی آن به اشیاء COM و غیره (اگر می‌خواستید مثلا رمزنگاری را به آن اضافه کنید باید Active-X می‌نوشتید و در سرور رجیستر می‌کردید!). این مورد اصلا قابل قیاس نیست با ASP.NET و امکانات دات نت فریم ورک.

@farbod
برای کلا جاوا اسکریپت هم کتابخانه‌های Unit test وجود دارد تا از این دلچرکین بودن خارج شوید:
QUnit

@محمد امین شریفی
اینبار انتخاب مایکروسافت درست بوده:
1- هزینه توسعه رو کاهش دادند. برای مثال هدف از Ajax Control Toolkit چیزی بوده شبیه به پلاگین‌های jQUery اما با هزینه بیشتر. اینبار شما هزاران پلاگین جی کوئری در اختیارتون هست و نه صرفا مجموعه‌ی Ajax Control Toolkit .
2- موردی رو که در مقاله بالا بهش اشاره شده و دلیل اصلی کنار گذاشتن ASP.NET Ajax بوده پایین بودن کارآیی ASP.NET Ajax است. هم حجم بالایی دارد و هم تبادلات شبکه‌ای حجیمی را به همراه دارد که در هر دو مورد جی کوئری بهینه‌تر است.
و یک سری موارد دیگر که قبلا بهش اشاره کرده بودم: (+)
3- انتخاب اصلی کتابخانه Ajax در ASP.NET MVC الان همین جی‌کوئری است و در مقاله فوق به یک سری افزونه و کتابخانه کمکی برای آن اشاره شده (که در حال توسعه و تکمیل است).

کم کم داره از این دست پروژه‌ها زیاد میشه. دقیقا بر همین اساس و ایده استفاده از قابلیت‌های پویای زبان:
Kynetic ORM: An ORM without configuration using C# 4.0 Dynamics, Generics and Reflection