لقد كنت قاسيًا بعض الشيء خلال عطلة نهاية الأسبوع وقررت ترقية المشروع إلى النظام الأساسي 2.0 نظرًا لإمكانية التعايش بين VS2003 و2005، فمن السهل نسبيًا التعامل مع المشكلة. قم بتثبيت الإصدار Pro لعام 2005، وافتح المشروع الأصلي، ثم قم بالترقية سيظهر المعالج تلقائيًا. يحتوي المشروع على 7 مشاريع فرعية. يتم تنفيذ كل المنطق والعرض في مشروع الخلفية. كل ملف في مشروع الويب الأمامي ينفذ فقط استدعاء أسلوب الخلفية، ولا يتم استخدام أي أساليب متقدمة في الخلفية الترقية سلسة للغاية.
لتلخيص ذلك، تم حذف ملفات المشروع في مشروع الويب. اتضح أنه تم أيضًا أخذ ملفين ASPX غير مرتبطين في الاعتبار أثناء عملية التجميع. لقد قمت بتجميعه وتحميله على الخادم وأبلغت عن خطأ. اكتشفت لاحقًا أن المشروع الذي تم تجميعه حديثًا لا يحتوي على ملف Dll الخاص بمشروع الويب، ولكنه لا يزال موجودًا في دليل الخادم. والنتيجة هي فوضى من المراجع الداخلية. احذف ملف Dll الخاص بمشروع الويب القديم وسيكون الأمر على ما يرام.
ثم خططت لتجربة وضع النشر، واستخدمت وظيفة موقع النشر في عنصر قائمة الإنشاء لـ VS2005 لتعيين الدليل للنشر إليه كانت عملية التجميع بطيئة للغاية. بعد اكتمال التجميع، تم إنشاء مجموعة من الأشياء في دليل bin، وأعتقد أن نسخ هذه الأشياء إلى الخادم من شأنه أن يلغي الحاجة إلى التجميع النظيف. اتضح أن عملية CSC لا تزال تظهر عند الوصول إلى الصفحة لأول مرة. بعد تبديل موقع الويب بأكمله، لا تزال هناك مجموعة من عمليات CSC، ولكن عملية التجميع كانت أسرع قليلاً من ذي قبل.
حدثت مشكلة خطيرة أخرى، ويبدو أن البرنامج يتم إعادة تشغيله تلقائيًا بعد فترة، مما أدى إلى تجميعه مرة أخرى. وفي وقت لاحق، ظهرت نافذة خطأ على الخادم تفيد بوجود خطأ في عملية w3wp.exe هو - هي؟ بعد تحديد "إلغاء الأمر"، تتم إعادة تشغيل ملف w3wp.exe تلقائيًا، وتبدأ جولة جديدة من إعادة الترجمة. حدثت هذه العملية ثلاث مرات، وكنت خائفًا جدًا لدرجة أنني عدت بسرعة إلى الإصدار 1.1. لقد ألقيت نظرة على عارض الأحداث ووجدت مجموعة من الاستثناءات التي لم تتم معالجتها، والتي كانت في الأساس أخطاء ذات قيم فارغة. الغريب أنه لم تكن هناك مشكلة في الإصدار 1.1 ولم يتم تغيير الكود.
وجدت لاحقًا مقالًا (يبدو أن أحدًا باللغة الصينية لم يذكره)، http://www.eggheadcafe.com/articles/20060305.asp يختلف التعامل مع الاستثناءات غير المعالجة في الإصدار 2.0 تمامًا عن التعامل مع الإصدار 1.1 مختلفة، 1.1 سوف يتجاهلها ما لم تؤثر على إنشاء الصفحة. وسيتسبب الإصدار 2.0 في الإبلاغ عن خطأ ما، مما يؤثر بشكل مباشر على تشغيل الموقع بأكمله. قد تبدو هذه مشكلة خطيرة، ولكنها تبدو أكثر منطقية، وإلا فسيستمر المبرمجون في تجاهل هذا الخطأ. ومع ذلك، وبسبب هذه المشكلة، فإن عدم القدرة على تبديل مواقع الويب يمثل أيضًا مشكلة خطيرة، لذلك لا تزال هناك حاجة إلى طريقة انتقال سلسة. كما ذكرنا سابقًا، تتمثل هذه الطريقة في كتابة HttpModule بنفسك للتعامل مع جميع الاستثناءات غير المعالجة وتسجيل معلومات الاستثناء في أحداث النظام، وهو أمر مفيد للمبرمجين في المعالجة. ويتم أيضًا توفير التعليمات البرمجية المصدر وتنزيل الملف الثنائي لـ HttpModule أعلاه أيضًا، بما في ذلك Demo WebApp.
لقد فهمت اليوم أخيرًا طريقة التجميع لإصدار 2.0 للنشر المسبق. من الخطأ استخدام VS لنشر موقع الويب. يجب عليك استخدام aspnet_compiler.exe للتجميع يدويًا، وتعتمد عملية التجميع على الإعدادات الفعلية لموقع الويب. بمعنى آخر، يجب عليك تحميل محتوى مشروع الويب إلى موقع الويب، وتعيين مسار موقع الويب في IIS، ثم استخدام aspnet_compile للتجميع محليًا تلك الموجودة في دليل ذاكرة التخزين المؤقت في WindowsMicrosoft.Net هي تمامًا نفس تلك التي تم إنشاؤها بواسطة csc.exe عندما يصل المستخدم فعليًا إلى الصفحة. بعد هذه الخطوة، لن يحدث أي إجراء تجميع عندما يقوم المستخدم بزيارة الموقع مرتين.
متعب جدا. بالمناسبة، فكرت في طريقة تبديل سلسة، حيث يتم الاحتفاظ بموقعين على الويب يشيران إلى دليلين مختلفين، أحدهما لا يحتوي على رأس مضيف، والآخر يحتوي على رأس مضيف للتحديث. بعد تحديث موقع الويب برأس المضيف، استخدم aspnet_compiler لتجميعه، ثم قم بتبديل رؤوس المضيف لموقعي الويب، بحيث يتم توجيه المستخدمين الذين تمت زيارتهم حديثًا إلى موقع الويب المترجم حديثًا، ولن يشعر المستخدم بأي تأخير. فقط قم بتحديث موقع آخر في المرة القادمة.
http://www.cnblogs.com/unfish/archive/2006/09/10/500230.html