این موضوع باعث اختلاف نظرهای زیادی شده بود. تا این که یک روز فهمیدم مشکل پروژه‌ی «الف» کجاست. علت، مقایسه‌ی آبجکت‌ها در حافظه بدون استفاده از ID آنها بود. این مقایسه در ASP.NET Development Server درست کار می‌کرد ولی در IIS درست کار نمی‌کرد. بعد از رفع مشکل هنوز این سوال برایم وجود داشت که چرا پروژه‌ی «ب» دچار چنین مشکلی نشده بود؟
یک روز که دنبال چیز دیگری در IIS بودم متوجه شدم که هر کدام از این پروژه‌ها از یک Application Pool مختلف برای کار خود استفاده می‌کنند. پروژه‌ی «ب» از Classic .NET AppPool استفاده می‌کرد ولی پروژه‌ی «الف» از DefaultAppPool. فرق این دو هم فقط در Pipline بود. اولی Classic بود و دومی Integrated. محض امتحان یک بار Application Pool پروژه‌ی «الف» را به Classic عوض کردم و آن مقایسه‌ای آبجکتی را دوباره به حالت بدون ID برگرداندم. در کمال ناباوری مشکل اولیه‌ی پروژه‌ی «الف» حل شد!
در واقع مشکل پروژه‌ی «الف» را می‌شد با درک بهتری از Pipeline زودتر کشف کرد که به علت بی‌سوادی و بی‌اطلاعی این موضوع اتفاق نیفتاده بود. البته الان می‌دانم علت خرابی کار Pipeline بوده ولی هنوز هم درک نمی‌کنم چرا.
دیدگاه‌ها
علت خاصي داره از كلمه‌ي بي سوادي استفاده مي‌كنيد؟
نوعي شكسته نفسي است؟
می‌خواهم عصبانیت خودم را از دست خودم نشان دهم که چرا چنین چیزی را زودتر از این نفهمیده بودم. ضمناً فکر می‌کنم یک جورایی علت این مشکل خود ما برنامه‌نویس‌ها هستیم که با بی‌تفاوتی از کنار بعضی چیزهای مهم می‌گذریم.
برای مسائل امنیتی، بهینه سازی و … بهتره به ازاء هر وب سایت یک Application Pool جدا داشته باشید.
این کار درستی نیست که همه وبسایتهای روی یک IIS را بر روی یک Application Pool آن هم Classic بگذارید.
شاید این کمک کنه علتش رو بفهمی. طولانی بود و من پرینت کردم بعدا (!) بخونمش
http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx