Titik masuk sebenarnya ke runtime .NET terjadi di beberapa kelas dan antarmuka yang tidak berdokumen (Terjemahan: Tentu saja, Anda dapat menggunakan Reflektor untuk melihat J). Sangat sedikit orang kecuali Microsoft yang mengetahui tentang antarmuka ini, dan orang-orang Microsoft Mereka tidak tertarik membicarakan detail ini. Mereka percaya bahwa detail implementasi ini tidak banyak berguna bagi pengembang yang menggunakan ASP.NET untuk mengembangkan aplikasi.
Proses pekerja (ASPNET_WP.EXE di IIS5, W3WP.EXE di IIS6) menghosting runtime .NET dan ISAPI DLL. Proses tersebut (proses pekerja) memanggil antarmuka kecil objek COM yang tidak dikelola dan pada akhirnya mengirimkan panggilan ke kelas ISAPIRuntime. Pada sebuah instance (Anotasi: Teks asli adalah subkelas instance dari kelas ISAPIRuntime, tetapi kelas ISAPIRuntime adalah kelas yang disegel, yang diduga merupakan kesalahan administrasi oleh penulis, atau subkelas di sini tidak berarti subkelas yang pertama). masuk ke runtime adalah Kelas tidak berdokumen ini mengimplementasikan antarmuka IISAPIRuntime (untuk spesifikasi pemanggil, antarmuka ini adalah antarmuka COM). Antarmuka COM yang mendasari berdasarkan IUnknown ini adalah antarmuka yang telah ditentukan yang diperluas dari ISAPI ke ASP.NET antarmuka dan tanda tangan panggilannya (menggunakan alat Reflektor .NET Lutz Roeder http://www.aisto.com/roeder/dotnet/). Ini adalah cara yang baik untuk menjelajahi proses langkah demi langkah ini.
Gambar 3 - Jika Anda ingin mempelajari lebih dalam antarmuka ini, buka Reflektor dan arahkan ke namespace System.Web.Hosting. DLL ISAPI membuka akses ke ASP.NET dengan memanggil antarmuka COM yang dihosting ASP.NET menerima non-biner tautan yang menunjuk ke penunjuk ISAPI ECB ini berisi kemampuan untuk mengakses antarmuka ISAPI lengkap yang digunakan untuk menerima permintaan dan mengirim respons kembali ke IIS.
Antarmuka IISAPIRuntime berfungsi sebagai titik antarmuka antara kode tidak terkelola yang diperluas dari ISAPI dan ASP.NET (terkait langsung di IIS6). (melalui Named Pipes di IIS5). Jika Anda melihat ke dalam kelas ini, Anda akan menemukan fungsi ProcessRequest dengan tanda tangan berikut:
[return: MarshalAs(UnmanagedType.I4)]
int ProcessRequest([In] IntPtr). ecb,
[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);
parameter ecb adalah Blok Kontrol Ekstensi ISAPI (Blok Kontrol Ekstensi), yang diteruskan ke fungsi ProcessRequest sebagai sumber daya yang tidak dikelola antarmuka Input dan output dasar, digunakan dengan objek Permintaan dan Respons. ISAPI ECB berisi semua informasi permintaan tingkat rendah, seperti variabel server, aliran input untuk variabel formulir, dan aliran output untuk menulis data kembali ke klien semua fungsi untuk mengakses sumber daya yang dapat diakses oleh permintaan ISAPI. ProcessRequest adalah titik masuk dan keluar awal untuk sumber daya ini (ecb) ke kode yang dikelola.
Ekstensi ISAPI menangani permintaan secara asinkron proses pekerja atau thread IIS, namun ECB akan tetap tersedia selama masa permintaan saat ini. ECB berisi mekanisme untuk memberi tahu ISAPI bahwa permintaan telah diproses (melalui metode ecb.ServerSupportFunction) (Anotasi: Selengkapnya Untuk informasi
, lihat artikel tentang pengembangan ekstensi ISAPI), yang menyebabkanECB
dilepaskan. Metode pemrosesan asinkron ini segera melepaskan thread pekerja ISAPI dan meneruskan pemrosesan ke thread terpisah yang dikelola oleh ASP.NET
menggunakannya secara internal untuk menerima informasi tentang permintaan saat ini, seperti variabel server dan data POST. Ini juga mengembalikan informasi ke server. ecb tetap dapat diakses (tetap hidup) sampai permintaan selesai atau batas waktu habis terus berkomunikasi dengannya hingga pemrosesan permintaan selesai. Outputnya ditulis ke aliran output ISAPI (menggunakan ecb.WriteClient()) dan permintaan selesai. Ekstensi ISAPI diberitahu bahwa pemrosesan permintaan telah selesai dan melepaskan ECB Implementasi ini sangat efisien, karena kelas .NET pada dasarnya hanyalah pembungkus yang sangat "tipis" di sekitar ISAPI ECB yang efisien dan tidak terkelola.
Memuat
.NET - agak misterius
Runtime .NET dimuat. Di sinilah segalanya menjadi sedikit kabur. Saya tidak menemukan dokumentasi apa pun tentang proses ini, dan karena kita berbicara tentang kode asli, tidak ada cara yang baik untuk mendekompilasi ISAPI DLL dan mencari tahu (kode yang memuat runtime .NET).
Tebakan terbaik yang dapat saya buat adalah ketika ekstensi ISAPI menerima permintaan pertama untuk ekstensi yang dipetakan ke ASP.NET, pekerjaan tersebut memuat runtime .NET. Setelah runtime ada, kode yang tidak dikelola dapat meminta instance ISAPIRuntime untuk direktori virtual tertentu jika belum ada. Setiap direktori virtual memiliki domain aplikasinya sendiri ( AppDomain), ketika aplikasi independen (mengacu pada program ASP.NET) dimulai, ISAPIRuntime selalu ada di domain aplikasi sejak proses startup. Instansiasi (Anotasi: harus mengacu pada instantiasi ISAPIRuntime) tampaknya melalui COM Hal ini dilakukan karena metode antarmuka diekspos sebagai metode yang dapat dipanggil COM
Saat pertama permintaan untuk direktori virtual datang, fungsi System.Web.Hosting.AppDomainFactory.Create() dipanggil untuk membuat instance ISAPIRuntime. Ini memulai proses startup aplikasi. Panggilan ini menerima jenis aplikasi, nama modul, dan informasi direktori virtual , yang digunakan oleh ASP.NET untuk membuat domain aplikasi dan memulai program ASP.NET untuk direktori virtual ini. Instance HttpRuntime (Anotasi: Teks asli adalah objek turunan HttpRuntime ini, tetapi HttpRuntime adalah kelas tersegel, yang dicurigai menjadi kesalahan dalam teks asli) dibuat di domain aplikasi baru. Setiap direktori virtual (yaitu, aplikasi ASP.NET dihosting) dihosting di domain aplikasi terpisah, dan hanya akan dimuat ketika ASP tertentu Program .NET diminta. Ekstensi ISAPI mengelola instance objek HttpRuntime ini dan merutekan permintaan internal berdasarkan direktori virtual yang diminta ke objek HttpRuntime yang benar.
Gambar 4 - Permintaan ISAPI dikirim ke pipa HTTP ASP.NET menggunakan beberapa kelas, antarmuka, dan pemanggilan banyak metode pabrik yang tidak terdokumentasi. Setiap aplikasi web/direktori virtual berjalan di domain aplikasinya sendiri, dan pemanggil ( Anotasi: ISAPI DLL) menyimpan referensi. ke antarmuka IISAPIRuntime untuk memicu pemrosesan permintaan ASP.NET.