نقطة الدخول الحقيقية إلى وقت تشغيل .NET تحدث في بعض الفئات والواجهات غير الموثقة (الترجمة: بالطبع، يمكنك استخدام Reflector لعرض J). عدد قليل جدًا من الأشخاص، باستثناء Microsoft، يعرفون عن هذه الواجهات، ورجال Microsoft ليسوا مهتمين بها يتحدثون عن هذه التفاصيل ويعتقدون أن تفاصيل التنفيذ هذه قليلة الفائدة للمطورين الذين يستخدمون ASP.NET لتطوير التطبيقات.
تستضيف العملية المنفذة (ASPNET_WP.EXE في IIS5 وW3WP.EXE في IIS6) وقت تشغيل .NET وISAPI DLL (العملية المنفذة) تستدعي واجهة صغيرة غير مُدارة لكائن COM وترسل في النهاية الاستدعاء إلى فئة ISAPIRuntime. على مثيل (تعليق توضيحي: النص الأصلي هو فئة فرعية من فئة ISAPIRuntime، ولكن فئة ISAPIRuntime هي فئة مختومة، والتي يشتبه المؤلف في أنها خطأ كتابي، أو الفئة الفرعية هنا لا تعني الفئة الفرعية الأولى). الإدخال في وقت التشغيل هو هذه الفئة غير الموثقة التي تطبق واجهة IISAPIRuntime (بالنسبة لمواصفات المتصل، هذه الواجهة هي واجهة COM. واجهة COM الأساسية هذه المستندة إلى IUnknown هي واجهة محددة مسبقًا ممتدة من ISAPI إلى ASP.NET). الواجهة وتوقيع المكالمة الخاص بها (باستخدام أداة .NET Reflector الممتازة من Lutz Roeder http://www.aisto.com/roeder/dotnet/)، وهذه طريقة جيدة لاستكشاف هذه العملية خطوة بخطوة.
الشكل 3 - إذا كنت تريد التعمق أكثر في هذه الواجهة، فافتح Reflector وأشر إلى مساحة الاسم System.Web.Hosting. يفتح ISAPI DLL الوصول إلى ASP.NET عن طريق استدعاء واجهة COM المستضافة التي تتلقى واجهة غير ثنائية رابط يشير إلى مؤشر ISAPI ECB المُدار. يحتوي هذا ECB على القدرة على الوصول إلى واجهة ISAPI الكاملة المستخدمة لتلقي الطلبات وإرسال الاستجابات مرة أخرى إلى IIS.
تعمل واجهة IISAPIRuntime كنقطة واجهة بين التعليمات البرمجية غير المُدارة الممتدة من ISAPI وASP.NET. (مرتبطة مباشرة بـ IIS6). (عبر الأنابيب المسماة في IIS5) إذا نظرت داخل هذه الفئة، فستجد وظيفة ProcessRequest بالتوقيع التالي:
[return: MarshalAs(UnmanagedType.I4)]
int ProcessRequest([In] IntPtr). ecb,
[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);
المعلمة ecb هي كتلة التحكم في ملحق ISAPI (كتلة التحكم في الامتداد)، والتي يتم تمريرها إلى وظيفة ProcessRequest كمورد غير مُدار تحتوي واجهة الإدخال والإخراج الأساسية، المستخدمة مع كائنات الطلب والاستجابة، على جميع معلومات الطلب ذات المستوى المنخفض، مثل متغيرات الخادم، وتدفقات الإدخال لمتغيرات النموذج، وتدفقات الإخراج لكتابة البيانات مرة أخرى إلى العميل كافة الوظائف الخاصة بالوصول إلى المورد الذي يمكن الوصول إليه بواسطة طلبات ISAPI. ProcessRequest هو نقطة الإدخال والخروج الأولية لهذا المورد (ecb) إلى تعليمات برمجية
مُدارة لملحقات ISAPI بشكل غير متزامن العملية المنفذة أو مؤشر ترابط IIS، لكن البنك المركزي الأوروبي سيظل متاحًا طوال مدة الطلب الحالي. يحتوي البنك المركزي الأوروبي على آلية للسماح لـ ISAPI بمعرفة أنه تمت معالجة الطلب (من خلال طريقة ecb.ServerSupportFunction) (تعليق توضيحي: المزيد للحصول على معلومات). ، راجع المقالة حول تطوير ملحقات ISAPI)، مما يتسبب في إصدار ECB. تقوم طريقة المعالجة غير المتزامنة هذه بتحرير مؤشر ترابط عامل ISAPI على الفور وتمرير المعالجة إلى مؤشر ترابط منفصل تتم إدارته بواسطة ASP.NET
ويتلقى مرجعًا إلى ecb و استخدمه داخليًا لتلقي معلومات حول الطلب الحالي، مثل متغيرات الخادم وبيانات POST، كما أنه يعيد المعلومات إلى الخادم. ويظل ecb متاحًا (يظل على قيد الحياة) حتى اكتمال الطلب أو انتهاء المهلة استمر في الاتصال به حتى اكتمال معالجة الطلب. تتم كتابة الإخراج إلى دفق إخراج ISAPI (باستخدام ecb.WriteClient()) ويتم إخطار ملحق ISAPI بأن معالجة الطلب قد اكتملت ويطلق البنك المركزي الأوروبي يعد هذا التنفيذ فعالاً للغاية، نظرًا لأن فئات .NET هي في الأساس مجرد غلاف "رفيع" للغاية حول برنامج ISAPI ECB الفعال وغير المُدار، وهو
أمر
غامض بعض الشيء
يتم تحميل وقت تشغيل .NET. هذا هو المكان الذي تصبح فيه الأمور غامضة بعض الشيء. لم أجد أي وثائق حول هذه العملية، وبما أننا نتحدث عن التعليمات البرمجية الأصلية، فلا توجد طريقة جيدة للقيام بذلك اكتشف ذلك (الكود الذي يقوم بتحميل وقت تشغيل .NET).
أفضل تخمين يمكنني القيام به هو أنه عندما يتلقى ملحق ISAPI الطلب الأول لملحق يتم تعيينه إلى ASP.NET، فإن المهمة التي تقوم بها العملية هي تحميل وقت تشغيل .NET. بمجرد وجود وقت التشغيل، يمكن للتعليمات البرمجية غير المُدارة أن تطلب مثيل ISAPIRuntime لدليل ظاهري محدد إذا لم يكن موجودًا بالفعل. يكون لكل دليل ظاهري مجال التطبيق الخاص به (AppDomain)، عندما يكون هناك تطبيق مستقل (يشير إلى برنامج ASP.NET). يبدو أن إنشاء مثيل ISAPIRuntime موجود دائمًا في مجال التطبيق (يجب أن يشير التعليق التوضيحي: يجب أن يشير إلى إنشاء مثيل ISAPIRuntime) من خلال COM. ويتم ذلك لأن أساليب الواجهة يتم كشفها كطرق قابلة للاستدعاء من
COM عندما يأتي طلب دليل ظاهري، يتم استدعاء الدالة System.Web.Hosting.AppDomainFactory.Create() لإنشاء مثيل لـ ISAPIRuntime، مما يؤدي إلى بدء عملية بدء تشغيل التطبيق. ويتلقى هذا الاستدعاء نوع التطبيق واسم الوحدة النمطية ومعلومات الدليل الظاهري ، والذي يستخدمه ASP.NET لإنشاء مجال التطبيق وبدء تشغيل برنامج ASP.NET لهذا الدليل الظاهري لمثيلات HttpRuntime (تعليق توضيحي: النص الأصلي هو كائن مشتق من HttpRuntime، لكن HttpRuntime عبارة عن فئة مختومة، وهي مشتبه بها. (يوجد خطأ في النص الأصلي) يتم إنشاؤها في مجال تطبيق جديد. تتم استضافة كل دليل ظاهري (أي تطبيق ASP.NET) في مجال تطبيق منفصل، ولن يتم تحميلها إلا عند وجود ASP محدد. يتم طلب برنامج .NET. يقوم ملحق ISAPI بإدارة مثيلات كائنات HttpRuntime وتوجيه الطلبات الداخلية بناءً على الدليل الظاهري المطلوب إلى كائن HttpRuntime الصحيح.
الشكل 4 - يتم إرسال طلبات ISAPI إلى خط أنابيب HTTP الخاص بـ ASP.NET باستخدام بعض الفئات والواجهات غير الموثقة واستدعاء العديد من أساليب المصنع، حيث يعمل كل تطبيق ويب/دليل افتراضي في مجال التطبيق الخاص به، ويحتفظ المتصل (التعليق التوضيحي: ISAPI DLL) بمرجع. إلى واجهة IISAPIRuntime لتشغيل معالجة طلب ASP.NET.