Kesalahan inisialisasi .NET Framework: Mengelola pengalaman pengguna
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 mungkin menampilkan pesan kesalahan kepada pengguna yang menjalankan aplikasi. Artikel ini memberikan 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: Mendebug Masalah Aktivasi CLR. Infrastruktur ini tidak boleh disamakan dengan log pengikatan rakitan, 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 dengan 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
Antarmuka pengguna untuk kesalahan inisialisasi
Jika sistem aktivasi CLR tidak dapat memuat versi runtime yang benar yang diperlukan oleh aplikasi, ini akan 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 galat berikut biasanya disajikan dalam situasi ini. Pengguna dapat memilih Ya untuk membuka situs web Microsoft tempat mereka dapat mengunduh versi .NET Framework yang benar untuk aplikasi tersebut.
Menyelesaikan kesalahan inisialisasi
Sebagai pengembang, Anda memiliki berbagai opsi untuk mengontrol pesan galat inisialisasi .NET Framework. Misalnya, Anda dapat menggunakan tanda API untuk mencegah pesan ditampilkan, seperti yang dibahas di bagian berikutnya. Namun, Anda masih harus menyelesaikan masalah yang mencegah aplikasi Anda memuat runtime yang diminta. Jika tidak, aplikasi Anda mungkin tidak berjalan sama sekali, atau beberapa fungsi mungkin tidak tersedia.
Untuk mengatasi masalah 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 petunjuk).
Untuk aplikasi .NET Framework 4: Instal paket .NET Framework 4 yang dapat didistribusikan ulang sebagai bagian dari penyiapan aplikasi Anda. Lihat Panduan Penyebaran untuk Pengembang.
Mengontrol pesan galat
Menampilkan pesan galat untuk mengomunikasikan bahwa versi .NET Framework yang diminta tidak ditemukan dapat dilihat sebagai layanan yang membantu atau gangguan kecil bagi pengguna. Dalam kedua kasus tersebut, Anda dapat mengontrol antarmuka pengguna ini dengan meneruskan tanda ke API aktivasi.
Metode ICLRMetaHostPolicy::GetRequestedRuntime menerima anggota enumerasi METAHOST_POLICY_FLAGS sebagai masukan. Anda dapat menyertakan tanda METAHOST_POLICY_SHOW_ERROR_DIALOG untuk meminta pesan gslst jika versi CLR yang diminta tidak ditemukan. Secara default, pesan kesalahan tidak ditampilkan. (Metode ICLRMetaHost::GetRuntime tidak menerima tanda ini, dan tidak menyediakan cara lain untuk menampilkan pesan galat.)
Windows menyediakan fungsi SetErrorMode yang dapat Anda gunakan untuk menyatakan apakah Anda ingin pesan galat ditampilkan sebagai hasil dari kode yang berjalan dalam proses Anda. Anda dapat menentukan tanda SEM_FAILCRITICALERRORS untuk mencegah pesan galat ditampilkan.
Namun, dalam beberapa skenario, penting untuk mengganti pengaturan SEM_FAILCRITICALERRORS yang ditetapkan oleh proses aplikasi. Misalnya, jika Anda memiliki komponen COM asli yang menghosting CLR dan yang dihosting dalam proses saat SEM_FAILCRITICALERRORS diatur, Anda mungkin ingin mengganti tanda, tergantung pada dampak menampilkan pesan kesalahan dalam proses aplikasi tertentu. Dalam hal ini, Anda dapat menggunakan salah satu tanda 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 antarmuka pengguna untuk host yang disediakan CLR
CLR menyertakan sekumpulan host untuk berbagai skenario, dan semua host ini menampilkan pesan kesalahan saat mereka mengalami masalah saat memuat versi runtime yang diperlukan. Tabel berikut menyediakan daftar host dan kebijakan pesan kesalahannya.
| Host CLR | Deskripsi | Kebijakan pesan kesalahan | Bisakah pesan kesalahan dinonaktifkan? |
|---|---|---|---|
| Host EXE terkelola | Meluncurkan EXE terkelola. | Ditampilkan jika ada versi .NET Framework yang hilang | No |
| Host COM terkelola | Memuat komponen COM terkelola ke dalam proses. | Ditampilkan jika ada versi .NET Framework yang hilang | Ya, dengan mengatur tanda SEM_FAILCRITICALERRORS |
| Host ClickOnce | Meluncurkan aplikasi ClickOnce. | Ditampilkan jika ada versi .NET Framework yang hilang, dimulai dengan .NET Framework 4.5 | No |
| Host XBAP | Meluncurkan aplikasi WPF XBAP. | Ditampilkan jika ada versi .NET Framework yang hilang, dimulai dengan .NET Framework 4.5 | No |
Perilaku dan antarmuka pengguna Windows 8
Sistem aktivasi CLR memberikan perilaku dan antarmuka pengguna yang sama pada Windows 8 seperti halnya pada versi lain dari sistem operasi Windows, kecuali jika 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 di 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 tersebut dibahas dalam artikel Instal .NET Framework 3.5 di Windows 11, Windows 10, Windows 8.1, dan Windows 8.
Catatan
.NET Framework 4.5 menggantikan .NET Framework 4 (CLR 4) di komputer pengguna. Oleh karena itu, aplikasi .NET Framework 4 berjalan 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 dijalankan 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: Mendebug Masalah Aktivasi CLR.
Lihat juga
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk