Initieringsfel för .NET Framework: Hantera användarupplevelsen
Kommentar
Den här artikeln är specifik för .NET Framework. Det gäller inte för nyare implementeringar av .NET, inklusive .NET 6 och senare versioner.
Clr-aktiveringssystemet (Common Language Runtime) avgör vilken version av CLR som ska användas för att köra kod för hanterade program. I vissa fall kanske aktiveringssystemet inte kan hitta en version av CLR som ska läsas in. Den här situationen inträffar vanligtvis när ett program kräver en CLR-version som är ogiltig eller inte är installerad på en viss dator. Om den begärda versionen inte hittas returnerar CLR-aktiveringssystemet en HRESULT-felkod från funktionen eller gränssnittet som anropades och kan visa ett felmeddelande för användaren som kör programmet. Den här artikeln innehåller en lista över HRESULT-koder och förklarar hur du kan förhindra att felmeddelandet visas.
CLR tillhandahåller loggningsinfrastruktur som hjälper dig att felsöka CLR-aktiveringsproblem, enligt beskrivningen i Så här felsöker du CLR-aktiveringsproblem. Den här infrastrukturen bör inte förväxlas med sammansättningsbindningsloggar som är helt annorlunda.
HRESULT-koder för CLR-aktivering
CLR-aktiverings-API:erna returnerar HRESULT-koder för att rapportera resultatet av en aktiveringsåtgärd till en värd. CLR-värdar bör alltid konsultera dessa returvärden innan du fortsätter med ytterligare åtgärder.
CLR_E_SHIM_RUNTIMELOAD
CLR_E_SHIM_RUNTIMEEXPORT
CLR_E_SHIM_INSTALLROOT
CLR_E_SHIM_INSTALLCOMP
CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND
CLR_E_SHIM_SHUTDOWNINPROGRESS
Användargränssnitt för initieringsfel
Om CLR-aktiveringssystemet inte kan läsa in rätt version av den körning som krävs av ett program visas ett felmeddelande till användarna om att deras dator inte är korrekt konfigurerad för att köra programmet och ger dem möjlighet att åtgärda situationen. Följande felmeddelande visas vanligtvis i den här situationen. Användaren kan välja Ja för att gå till en Microsoft-webbplats där de kan ladda ned rätt .NET Framework-version för programmet.
Lösa initieringsfelet
Som utvecklare har du en mängd olika alternativ för att styra .NET Framework-initieringsfelmeddelandet. Du kan till exempel använda en API-flagga för att förhindra att meddelandet visas, enligt beskrivningen i nästa avsnitt. Du måste dock fortfarande lösa problemet som hindrade programmet från att läsa in den begärda körningen. Annars kanske programmet inte körs alls, eller så är vissa funktioner kanske inte tillgängliga.
För att lösa de underliggande problemen och ge den bästa användarupplevelsen (färre felmeddelanden) rekommenderar vi följande:
För .NET Framework 3.5-program (och tidigare) program: Konfigurera ditt program så att det stöder .NET Framework 4- eller senare versioner (se instruktioner).
För .NET Framework 4-program: Installera det omdistribuerbara .NET Framework 4-paketet som en del av programkonfigurationen. Se Distributionsguide för utvecklare.
Kontrollera felmeddelandet
Att visa ett felmeddelande om att en begärd .NET Framework-version inte hittades kan ses som antingen en användbar tjänst eller en mindre irritation för användarna. I båda fallen kan du styra det här användargränssnittet genom att skicka flaggor till aktiverings-API:erna.
Metoden ICLRMetaHostPolicy::GetRequestedRuntime accepterar en METAHOST_POLICY_FLAGS uppräkningsmedlem som indata. Du kan ta med flaggan METAHOST_POLICY_SHOW_ERROR_DIALOG för att begära ett felmeddelande om den begärda versionen av CLR inte hittas. Som standard visas inte felmeddelandet. (Den ICLRMetaHost::GetRuntime-metoden accepterar inte den här flaggan och ger inget annat sätt att visa felmeddelandet.)
Windows tillhandahåller en SetErrorMode-funktion som du kan använda för att deklarera om du vill att felmeddelanden ska visas som ett resultat av kod som körs i processen. Du kan ange flaggan SEM_FAILCRITICALERRORS för att förhindra att felmeddelandet visas.
I vissa scenarier är det dock viktigt att åsidosätta den SEM_FAILCRITICALERRORS inställning som anges av en programprocess. Om du till exempel har en inbyggd COM-komponent som är värd för CLR och som finns i en process där SEM_FAILCRITICALERRORS anges, kanske du vill åsidosätta flaggan, beroende på effekten av att visa felmeddelanden i den specifika programprocessen. I det här fallet kan du använda någon av följande flaggor för att åsidosätta SEM_FAILCRITICALERRORS:
Använd METAHOST_POLICY_IGNORE_ERROR_MODE med metoden ICLRMetaHostPolicy::GetRequestedRuntime .
Använd RUNTIME_INFO_IGNORE_ERROR_MODE med funktionen GetRequestedRuntimeInfo .
Användargränssnittsprincip för CLR-tillhandahållna värdar
CLR innehåller en uppsättning värdar för en mängd olika scenarier, och alla dessa värdar visar ett felmeddelande när de stöter på problem med att läsa in den nödvändiga versionen av körningen. Följande tabell innehåller en lista över värdar och deras principer för felmeddelanden.
| CLR-värd | beskrivning | Princip för felmeddelande | Kan felmeddelandet inaktiveras? |
|---|---|---|---|
| Hanterad EXE-värd | Startar hanterade EXE:er. | Visas om en .NET Framework-version saknas | Nej |
| Hanterad COM-värd | Läser in hanterade COM-komponenter i en process. | Visas om en .NET Framework-version saknas | Ja, genom att ange flaggan SEM_FAILCRITICALERRORS |
| ClickOnce-värd | Startar ClickOnce-program. | Visas om en .NET Framework-version saknas, från och med .NET Framework 4.5 | Nej |
| XBAP-värd | Startar WPF XBAP-program. | Visas om en .NET Framework-version saknas, från och med .NET Framework 4.5 | Nej |
Beteende och användargränssnitt för Windows 8
CLR-aktiveringssystemet har samma beteende och användargränssnitt på Windows 8 som på andra versioner av Windows-operativsystemet, förutom när det uppstår problem med att läsa in CLR 2.0. Windows 8 innehåller .NET Framework 4.5, som använder CLR 4.5. Windows 8 innehåller dock inte .NET Framework 2.0, 3.0 eller 3.5, som alla använder CLR 2.0. Därför körs inte program som är beroende av CLR 2.0 på Windows 8 som standard. I stället visas följande dialogruta så att användarna kan installera .NET Framework 3.5. Användare kan också aktivera .NET Framework 3.5 i Kontrolna tabla. Båda alternativen beskrivs i artikeln Installera .NET Framework 3.5 på Windows 11, Windows 10, Windows 8.1 och Windows 8.
Kommentar
.NET Framework 4.5 ersätter .NET Framework 4 (CLR 4) på användarens dator. Därför körs .NET Framework 4-program sömlöst, utan att den här dialogrutan visas, i Windows 8.
När .NET Framework 3.5 har installerats kan användare köra program som är beroende av .NET Framework 2.0, 3.0 eller 3.5 på sina Windows 8-datorer. De kan också köra .NET Framework 1.0- och 1.1-program, förutsatt att dessa program inte uttryckligen har konfigurerats att köras endast på .NET Framework 1.0 eller 1.1. Se Migrera från .NET Framework 1.1.
Från och med .NET Framework 4.5 har CLR-aktiveringsloggning förbättrats för att inkludera loggposter som registrerar när och varför initieringsfelmeddelandet visas. Mer information finns i Så här felsöker du CLR-aktiveringsproblem.
