Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Nota
Artikel ini khusus untuk .NET Framework. Ini tidak berlaku untuk implementasi .NET yang lebih baru, termasuk .NET 6 dan versi yang lebih baru.
Sistem aktivasi runtime bahasa umum (CLR) menentukan versi CLR yang akan digunakan untuk menjalankan kode aplikasi terkelola. Dalam beberapa kasus, sistem aktivasi mungkin tidak dapat menemukan versi CLR untuk dimuat. Situasi ini biasanya terjadi ketika aplikasi memerlukan versi CLR yang tidak valid atau tidak diinstal pada komputer tertentu. Jika versi yang diminta tidak ditemukan, sistem aktivasi CLR mengembalikan kode kesalahan HRESULT dari fungsi atau antarmuka yang dipanggil, dan dapat menampilkan pesan kesalahan kepada pengguna yang menjalankan aplikasi. Artikel ini menyediakan daftar kode HRESULT dan menjelaskan bagaimana Anda dapat mencegah pesan kesalahan ditampilkan.
CLR menyediakan infrastruktur pengelogan untuk membantu Anda men-debug masalah aktivasi CLR, seperti yang dijelaskan dalam Cara: Debug Masalah Aktivasi CLR. Infrastruktur ini tidak boleh dikacaukan dengan log pengikatan perakitan, yang sama sekali berbeda.
Kode HRESULT aktivasi CLR
API aktivasi CLR mengembalikan kode HRESULT untuk melaporkan hasil operasi aktivasi ke host. Host CLR harus selalu berkonsultasi dengan nilai pengembalian ini sebelum melanjutkan operasi tambahan.
CLR_E_SHIM_RUNTIMELOAD
CLR_E_SHIM_RUNTIMEEXPORT
CLR_E_SHIM_INSTALLROOT
CLR_E_SHIM_INSTALLCOMP
CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND
CLR_E_SHIM_SHUTDOWNINPROGRESS
UI untuk kesalahan inisialisasi
Jika sistem aktivasi CLR tidak dapat memuat versi runtime yang benar yang diperlukan oleh aplikasi, sistem ini menampilkan pesan kesalahan kepada pengguna untuk memberi tahu mereka bahwa komputer mereka tidak dikonfigurasi dengan benar untuk menjalankan aplikasi, dan memberi mereka kesempatan untuk memperbaiki situasi. Pesan kesalahan berikut biasanya disajikan dalam situasi ini. Pengguna dapat memilih Ya untuk masuk ke situs web Microsoft tempat mereka dapat mengunduh versi .NET Framework yang benar untuk aplikasi.
Mengatasi kesalahan inisialisasi
Sebagai pengembang, Anda memiliki berbagai opsi untuk mengontrol pesan kesalahan inisialisasi .NET Framework. Misalnya, Anda dapat menggunakan bendera API untuk mencegah pesan ditampilkan, seperti yang dibahas di bagian berikutnya. Namun, Anda masih harus mengatasi masalah yang mencegah aplikasi Anda memuat runtime yang diminta. Jika tidak, aplikasi Anda mungkin tidak berjalan sama sekali, atau beberapa fungsionalitas mungkin tidak tersedia.
Untuk mengatasi masalah yang mendasar dan memberikan pengalaman pengguna terbaik (lebih sedikit pesan kesalahan), kami merekomendasikan hal berikut:
Untuk aplikasi .NET Framework 3.5 (dan yang lebih lama): Konfigurasikan aplikasi Anda untuk mendukung .NET Framework 4 atau versi yang lebih baru (lihat instruksi).
Untuk aplikasi .NET Framework 4: Instal paket yang dapat didistribusikan ulang .NET Framework 4 sebagai bagian dari penyiapan aplikasi Anda. Lihat Panduan Penyebaran untuk Pengembang.
Mengontrol pesan kesalahan
Menampilkan pesan kesalahan untuk mengomunikasikan bahwa versi .NET Framework yang diminta tidak ditemukan dapat dilihat sebagai layanan yang bermanfaat atau gangguan kecil kepada pengguna. Dalam kedua kasus, Anda dapat mengontrol UI ini dengan meneruskan bendera ke API aktivasi.
Metode ICLRMetaHostPolicy::GetRequestedRuntime menerima anggota enumerasi METAHOST_POLICY_FLAGS sebagai input. Anda dapat menyertakan bendera METAHOST_POLICY_SHOW_ERROR_DIALOG untuk meminta pesan kesalahan jika versi CLR yang diminta tidak ditemukan. Secara default, pesan kesalahan tidak ditampilkan. (Metode ICLRMetaHost::GetRuntime tidak menerima bendera ini, dan tidak menyediakan cara lain untuk menampilkan pesan kesalahan.)
Windows menyediakan fungsi SetErrorMode yang dapat Anda gunakan untuk mendeklarasikan apakah Anda ingin pesan kesalahan ditampilkan sebagai hasil dari kode yang berjalan dalam proses Anda. Anda dapat menentukan bendera SEM_FAILCRITICALERRORS untuk mencegah pesan kesalahan ditampilkan.
Namun, dalam beberapa skenario, penting untuk mengambil alih pengaturan SEM_FAILCRITICALERRORS yang ditetapkan oleh proses aplikasi. Misalnya, jika Anda memiliki komponen COM bawaan yang menghosting CLR dan dihosting dalam proses di mana SEM_FAILCRITICALERRORS diatur, Anda mungkin ingin mengubah pengaturan bendera tersebut, tergantung pada dampak dari menampilkan pesan kesalahan dalam proses aplikasi tertentu. Dalam hal ini, Anda dapat menggunakan salah satu bendera berikut untuk mengambil alih SEM_FAILCRITICALERRORS:
Gunakan METAHOST_POLICY_IGNORE_ERROR_MODE dengan metode ICLRMetaHostPolicy::GetRequestedRuntime .
Gunakan RUNTIME_INFO_IGNORE_ERROR_MODE dengan fungsi GetRequestedRuntimeInfo .
Kebijakan UI untuk host yang disediakan CLR
CLR menyertakan sekumpulan host untuk berbagai skenario, dan host ini semuanya menampilkan pesan kesalahan ketika mereka mengalami masalah saat memuat versi runtime yang diperlukan. Tabel berikut ini menyediakan daftar host dan kebijakan pesan kesalahannya.
| Host CLR | Deskripsi | Kebijakan pesan kesalahan | Bisakah pesan kesalahan dinonaktifkan? |
|---|---|---|---|
| Pengelola EXE | Meluncurkan program yang dikelola. | Ditampilkan dalam kasus versi .NET Framework yang hilang | Tidak. |
| Host COM yang diatur | Memuat komponen COM yang dikelola ke dalam suatu proses. | Ditampilkan dalam kasus versi .NET Framework yang hilang | Ya, dengan mengatur parameter SEM_FAILCRITICALERRORS |
| Host ClickOnce | Meluncurkan aplikasi ClickOnce. | Ditampilkan dalam kasus versi .NET Framework yang hilang, dimulai dengan .NET Framework 4.5 | Tidak. |
| Host XBAP | Meluncurkan aplikasi WPF XBAP. | Ditampilkan dalam kasus versi .NET Framework yang hilang, dimulai dengan .NET Framework 4.5 | Tidak. |
Perilaku dan UI Windows 8
Sistem aktivasi CLR menyediakan perilaku dan UI yang sama pada Windows 8 seperti pada versi lain dari sistem operasi Windows, kecuali ketika mengalami masalah saat memuat CLR 2.0. Windows 8 menyertakan .NET Framework 4.5, yang menggunakan CLR 4.5. Namun, Windows 8 tidak menyertakan .NET Framework 2.0, 3.0, atau 3.5, yang semuanya menggunakan CLR 2.0. Akibatnya, aplikasi yang bergantung pada CLR 2.0 tidak berjalan pada Windows 8 secara default. Sebagai gantinya, mereka menampilkan kotak dialog berikut untuk memungkinkan pengguna menginstal .NET Framework 3.5. Pengguna juga dapat mengaktifkan .NET Framework 3.5 di Panel Kontrol. Kedua opsi dibahas dalam artikel Menginstal .NET Framework 3.5 di Windows 11, Windows 10, Windows 8.1, dan Windows 8.
Nota
.NET Framework 4.5 menggantikan .NET Framework 4 (CLR 4) di komputer pengguna. Oleh karena itu, aplikasi .NET Framework 4 berjalan dengan mulus, tanpa menampilkan kotak dialog ini, pada Windows 8.
Ketika .NET Framework 3.5 diinstal, pengguna dapat menjalankan aplikasi yang bergantung pada .NET Framework 2.0, 3.0, atau 3.5 di komputer Windows 8 mereka. Mereka juga dapat menjalankan aplikasi .NET Framework 1.0 dan 1.1, asalkan aplikasi tersebut tidak dikonfigurasi secara eksplisit untuk berjalan hanya pada .NET Framework 1.0 atau 1.1. Lihat Migrasi dari .NET Framework 1.1.
Dimulai dengan .NET Framework 4.5, pengelogan aktivasi CLR telah ditingkatkan untuk menyertakan entri log yang merekam kapan dan mengapa pesan kesalahan inisialisasi ditampilkan. Untuk informasi selengkapnya, lihat Cara: Men-debug Masalah Aktivasi CLR.
Lihat juga
Berkolaborasi dengan kami di GitHub
Sumber untuk konten ini dapat ditemukan di GitHub, yang juga dapat Anda gunakan untuk membuat dan meninjau masalah dan menarik permintaan. Untuk informasi selengkapnya, lihat panduan kontributor kami.
