لا يمكن تطبيق ASP.NET على الويب تجميعًا

Question

قمت بنشر تطبيق ASP.NET على الويب الليلة الماضية وأنا عندما استيقظت هذا الصباح ، كان بطيئًا جدًا ، وأحيانًا أرمي خطأ "غير متوفر".

راجعت عارض الحدث وتم ملؤه بهذه الأخطاء:

حدث استثناء غير معتمد وتم إنهاء العملية.

الاستثناء: System.Runtime.Serialization.SerializationException

الرسالة: غير قادر على العثور على تجميع 'monotorrent ، الإصدار = 0.80.0.0 ، الثقافة = محايد ، publickeytoken = null'

لقد شعرت بالحيرة لأنه كان يعمل بشكل مثالي عندما قمت بنشره (مطلوب موحّد لاسترداد عدد البذور/العلب من أجل سيل معين من المتتبع - كان هذا يعمل بشكل جيد) ، لكنه لم يعد يعمل ، وكلما كان رمزًا يستخدم Monotorrent يتورط ، عملية العمال مجرد تعطل.

monotorrent.dll في / bin / directory.

---

تحديث 6/4/10: قمت بتجميع رمز مصدر Monotorrent مع بقية تطبيق الويب الخاص بي ، لكنه لا يزال يتعطل كلما استخدم Monotorrent. ومع ذلك ، فإنه يقول الآن Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. هنا ، OpenPeer هو اسم مجموعة تطبيق الويب.

Answer 1

يمكن أن يحدث هذا في هذه الظروف:

ينشئ تطبيق ASP.NET موضوعًا للخلفية ، والذي يلقي استثناءً غير معطل. يبدو أن ASP.NET يمسك بالاستثناء ويريد تسجيله إلى سجل الحدث. للقيام بذلك ، يرسل هذا الاستثناء من مجال تطبيق تطبيق الويب إلى مجال التطبيق الخاص به (الافتراضي لعملية W3WP). هذا يحتاج إلى تسلسل/إزالة التسلسل للاستثناء.

إذا كان الاستثناء مخصصًا (أي محدده تطبيق الويب) ، فلا يمكن إلغاء التخلص منه في مجال التطبيق الرئيسي لـ ASP.NET لأن التجميع الذي يحدد الاستثناء عادة ما يكون في دليل صندوق تطبيق الويب ، وليس حيث W3WP.exe (C: windows system32 inetsrv). هذا يسبب استثناء التسلسل وتعطل W3WP.

هناك طرق محتملة لإصلاح المشكلة (في أمر تفضيل شخصي للغاية):

1. انسخ DLL المفقود في C: Windows System32 inetsrv
2. تثبيت DLL المفقود في GAC
3. قم بإزالة سبب الاستثناء (من الصعب القيام به من القول ، كما نقول باللغة الفرنسية)
4. التقط كل الاستثناءات من خيط الخلفية بنفسك وقم بتسجيل الدخول بنفسك.

ملاحظات:

• إذا تم استخدام WCF وكان الاستثناء غير المطلوب هو justexception ، فإن WCF يبتلعها ولا يوجد أي حادث
• إذا كان الاستثناء غير المطلوب في موضوع طلب الويب ، فهناك شاشة صفراء للموت ، وليس استثناء التسلسل هذا
• يبدو حقًا وكأنه خطأ في ASP.NET
• ما سبق هو في الواقع ملخص لتحقيقاتي في هذه القضية أمس وهي نظرية فقط. لقد اختبرت الإصلاحات 1 و 4 ، وكذلك باستخدام خطأ.

Answer 2

محاولة مسح ملفات Temp ASP.NET. لقد تم حل بعض المشكلات الغريبة من قبل بالنسبة لي.

غير ذلك، الانصهار قد تلقي بعض الضوء.

تحديث: @charlie - لست متأكدًا مما يجب صنعه من هذه السجلات ... يبدو أن السجل الفاشل هو من AppDomain مختلف. لاحظ أن AppBase تم تعيينه على "File: /// C:/Windows/System32/InetSRV/" و AppName هو w3wp.exe.

أنا متأكد من أن عارض الحدث يجب أن يعرض معرف التطبيق: LM/W3SVC/#/ROOT إذا كان AppDomain الافتراضي أيضًا. في هذه المرحلة ، كل ما لدي هو التخمينات العشوائية.

1. لقد لاحظت أنك تعمل X64 ... هل ربما يكون أحاديًا تتطلب x86?
2. هل قمت بفحص مضاعفة من أن الدليل هو تطبيق IIS ، وتم تكوينه للإصدار الصحيح من ASP.NET؟
3. هل هناك بعض التطبيقات الأخرى التي تستخدم Monotorrent على هذا الخادم؟ ربما خدمة WCF أو شيء من هذا القبيل؟ لست متأكدًا من أين يحدث التسلسل ....
4. حاول تثبيت حدث التجميع وتحميله يدويًا.
5. هل يمكنك إعادة الشراء على آلة التطوير؟ إذا لم يكن الأمر كذلك ، فربما يكون تثبيت FX Borked. إلغاء التثبيت وإعادة التثبيت.
6. هل إعادة تشغيل أو إعادة تدوير أو إيقاف/بدء تشغيل AppPool إصلاح المشكلة مؤقتًا ، أو يتسبب في ظهور المشكلة؟

قد ترغب في كتابة نص لقطة الشاشة أيضًا حتى تحصل على بعض حب Google ....

Answer 3

إليك بعض الأشياء التي يمكنك تجربتها ..

1.) دليل Flush ASP.NET TEMP. أعد تشغيل IIS و تجمع تطبيقات إعادة التدوير.

2.) تأكد من تشغيل تطبيق الويب الخاص بك الكامل إذا كان حقا يحتاج إلى الثقة الكاملة.

3.) خذ التجميع ، حاول استخدامه في تطبيق ASP.NET آخر و قم بتشغيل تطبيق الاختبار على خادم منفصل. قد يساعدك هذا في تشخيص المشكلة. حاول أيضًا تشغيل تطبيق ASP.NET Test على نفس الخادم ولكن في تجمع التطبيقات المنفصل.

4.) تأكد من يعمل موقع IIS الخاص بتطبيقك تحت حساب المستخدم مع PROVILIGES الضرورية. حاول تشغيل التطبيق ضمن Administratotr كمستخدم.

تحرير -1

5.) تحقق أيضًا مما إذا كان إصدار التجميع هو نفسه كما هو مذكور في web.config. إذا كان هناك عدم تطابق نسخة ، فيمكنك القيام به التجميع إعادة توجيه في web.config.

6.) أيضًا جرب Registaering التجميع في GAC ومعرفة ما إذا كان يتم تحميله بشكل صحيح.

EDIT-2

7.) حاول إعادة تأجيل دعم ASP.NET على الخادم أو ربما تساعد إعادة استخدام وقت تشغيل Framework. قد لا يكون هذا حلًا مؤكدًا ولكن بالنظر إلى حالة المشكلة قد نرغب في تجربة حلول مختلفة.

8.) تأكد من أنك لا تفتقد أي شيء التحديث الحاسم لخادم Windows الخاص بك برنامج.

Answer 4

أحاول أن أعطيك بعض الأفكار - ماذا أفعل إذا كنت في وضعك.

بادئ ذي بدء ، ألقي نظرة طويلة على monotorrent.dll قبل بعض الأيام التي تقوم فيها بتقديم سؤالك ، وأبحث عنه مرة أخرى اليوم. لقد وجدت والوظيفة التي تحميل DLL. رأيي الأول هو أن هناك علاقة بالأذونات.

آمل أن يكون لديك وصول إلى الخادم - أليس كذلك؟

خطواتي الأولى هي:

تأكد, ، للقراءة ، وتنفيذها بواسطة تطبيق ASP.NET الخاص بك. في بعض الأحيان ، لم تحصل على نسخة من DLL ، على أذونات الدليل ولكنها تنقل أذوناته الخاصة. للتحقق مما إذا كان لدى DLL أذونات مختلفة من الباقي ، ما عليك سوى النقر بزر الماوس الأيمن وشاهد الخصائص | الأمن ، ثم انتقل إلى دليل بن وافعل الشيء نفسه ، وقارن أذونات الأمن. إذا كانت مختلفة ، فقم بتطبيق أذونات الدليل مرة أخرى وتأكد من أن DLL ورثته الدليل.

خطوتي الثانية

قم بتنزيل ProcessMonitor من sysinternals

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

تشغيل ProcessMonitor وحاول إعادة إنشاء الخطأ, ، توقف عن ذلك وتحليله لمعرفة أين ولماذا يحصل DLL على الأذونات المرفوضة. مع ProcessMonitor ، يمكنك حتى معرفة ما إذا كان هناك أي DLL لا يمكن العثور عليه!

لقد قمت بفحص DLLS Monotorrent ولم أجد أي شيء غير عادي. لديه مكالمات Kerner32.dll ، ويستخدم رمزًا غير آمن لتشغيله ، لا شيء مميز جدًا.

لذلك إذا قمت بذلك خطوتين وأعطيني بعض الملاحظات ، فربما يمكنني الذهاب أبعد من ذلك. (إذا لم تحل بواسطتك وما تجده)

Answer 5

ننصح بإعداد الصيانة العادية ربما مرة واحدة في الأسبوع في ليلة الأحد وما إلى ذلك للمتابعة ،

1. احذف جميع الملفات المؤقتة
2. حذف جميع ملفات ASP.NET IIS المؤقتة
3. إعادة تشغيل الخادم

المشكلة هي أن تطبيقات الويب ASP.NET تتسبب في ترك الكثير من الملفات المؤقتة في القرص ، بسبب التجميع الديناميكي لـ regex ، وتجميعات seriliazation ، إلخ ، لا يتم حذف هذه الأشياء المؤقتة أبدًا ، ويبدأ المزيد والمزيد من الخردة في جمعها في مواقع مؤقتة ، يصبح ASP.NET أبطأ وأبطأ ، وتأتي نقطة حيث يصل قرص إزالة الذاكرة إلى نقطة عالية للغاية ، تبدأ الأمور في الفشل.

لا يوجد أي شخص يحب إعادة تشغيل الخادم مرة واحدة في الأسبوع ، لكنني أتذكر أنه لم يكن لدينا أي خيار ، في ASP.NET 1.1 كان لدينا نظام مستقر بعد إعادة التشغيل كل يوم ، في ASP.NET 2.0 فصاعدًا ، من الجيد إعادة تشغيل جدولة مرة واحدة في الأسبوع .

Answer 6

لقد وجدت هذه المشكلة وقد فعلت كل شيء قدر الإمكان ، مثل Clear Temp File ، وإعادة تشغيل الخادم ، وحذف وإضافة المرجع وأعيد أيضًا بناء الحل. ومع ذلك لا يمكنني حل هذه المشكلة. أخيرًا ، أقوم بنقل فئة الكيان الخاصة بي (يحتاجون تقريبًا إلى التسلسل) إلى مجلد جديد أضفته إلى المشروع ثم حل هذه المشكلة.

هذه الطريقة تعمل بالنسبة لي.

Answer 7

هل المنطقة الزمنية الخادم مختلفة عن المنطقة الزمنية؟ لقد واجهت هذه المشكلة عند نشر ملفات الموارد ، كان وقت الترجمة في المستقبل حتى يفشلوا في التحميل.

Answer 8

أعتقد أن لديك الكثير من الاتصالات المفتوحة ولكن غير مغلقة. أعني عدم إرجاع الاتصالات إلى حمام السباحة. يبدو الأمر جيدًا ، عندما تبدأ التطبيق ، ولكن بعد مرور بعض الوقت لا يوجد سوى العديد من المقابس المتوفرة في حمام السباحة وتذهب بطيئًا. شيء آخر - قد يحتفظ اتصال غير مغلق DLL في الذاكرة ، وليس السماح بإصدار المعالج. حاول تصحيح تدمير الكائن.

Answer 9

أعلم أن الأمر بسيط ولكن كان لدي هذه المشكلة مرة واحدة و itwas لأنني كان لدي مشروع تطبيق ويب يحتوي

    References

المجلد وأنا قمت بنسخ ملفاتي للتو إلى

    Bin

المجلد ، في أي تطبيق .NET Web في خصائص المشروع Windows, ، أ علامة تبويب المسار المرجعي متاح والذي يجب أن يتم تضمينه بشكل افتراضي. تحقق من هذا الخيار وكذلك تبويب علامة التبويب في نافذة خصائص المشروع أيّ مسار الاخراج يكون مثل سلة مهملات