Initialisatiefouten van .NET Framework: de gebruikerservaring beheren
Notitie
Dit artikel is specifiek voor .NET Framework. Dit geldt niet voor nieuwere implementaties van .NET, waaronder .NET 6 en nieuwere versies.
Het CLR-activeringssysteem (Common Language Runtime) bepaalt de versie van de CLR die wordt gebruikt om beheerde toepassingscode uit te voeren. In sommige gevallen kan het activeringssysteem mogelijk geen versie van de CLR vinden die moet worden geladen. Deze situatie treedt meestal op wanneer voor een toepassing een CLR-versie is vereist die ongeldig is of niet is geïnstalleerd op een bepaalde computer. Als de aangevraagde versie niet wordt gevonden, retourneert het CLR-activeringssysteem een HRESULT-foutcode van de functie of interface die is aangeroepen en wordt mogelijk een foutbericht weergegeven aan de gebruiker die de toepassing uitvoert. In dit artikel vindt u een lijst met HRESULT-codes en wordt uitgelegd hoe u kunt voorkomen dat het foutbericht wordt weergegeven.
De CLR biedt een infrastructuur voor logboekregistratie waarmee u problemen met CLR-activering kunt opsporen, zoals beschreven in Procedure: Problemen met clr-activering opsporen. Deze infrastructuur mag niet worden verward met assemblybindingslogboeken, die volledig anders zijn.
CLR-activering HRESULT-codes
De CLR-activerings-API's retourneren HRESULT-codes om het resultaat van een activeringsbewerking aan een host te rapporteren. CLR-hosts moeten deze retourwaarden altijd raadplegen voordat u doorgaat met aanvullende bewerkingen.
CLR_E_SHIM_RUNTIMELOAD
CLR_E_SHIM_RUNTIMEEXPORT
CLR_E_SHIM_INSTALLROOT
CLR_E_SHIM_INSTALLCOMP
CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND
CLR_E_SHIM_SHUTDOWNINPROGRESS
Gebruikersinterface voor initialisatiefouten
Als het CLR-activeringssysteem niet de juiste versie van de runtime kan laden die door een toepassing is vereist, wordt er een foutbericht weergegeven aan gebruikers om hen te laten weten dat hun computer niet correct is geconfigureerd om de toepassing uit te voeren en hen de mogelijkheid biedt om de situatie te verhelpen. Het volgende foutbericht wordt meestal weergegeven in deze situatie. De gebruiker kan Ja kiezen om naar een Microsoft-website te gaan waar ze de juiste .NET Framework-versie voor de toepassing kunnen downloaden.
De initialisatiefout oplossen
Als ontwikkelaar hebt u verschillende opties voor het beheren van het initialisatiefoutbericht van .NET Framework. U kunt bijvoorbeeld een API-vlag gebruiken om te voorkomen dat het bericht wordt weergegeven, zoals beschreven in de volgende sectie. U moet het probleem echter nog steeds oplossen waardoor uw toepassing de aangevraagde runtime niet kan laden. Anders kan uw toepassing helemaal niet worden uitgevoerd of is bepaalde functionaliteit mogelijk niet beschikbaar.
Als u de onderliggende problemen wilt oplossen en de beste gebruikerservaring wilt bieden (minder foutberichten), raden we het volgende aan:
Voor .NET Framework 3.5 -toepassingen (en eerder): Configureer uw toepassing ter ondersteuning van .NET Framework 4 of hoger (zie de instructies).
Voor .NET Framework 4-toepassingen: Installeer het herdistribueerbare pakket van .NET Framework 4 als onderdeel van de installatie van uw toepassing. Zie de implementatiehandleiding voor ontwikkelaars.
Het foutbericht beheren
Het weergeven van een foutbericht om te communiceren dat een aangevraagde .NET Framework-versie niet is gevonden, kan worden weergegeven als een nuttige service of een kleine ergernis voor gebruikers. In beide gevallen kunt u deze gebruikersinterface beheren door vlaggen door te geven aan de activerings-API's.
De methode ICLRMetaHostPolicy::GetRequestedRuntime accepteert een METAHOST_POLICY_FLAGS opsommingslid als invoer. U kunt de vlag METAHOST_POLICY_SHOW_ERROR_DIALOG opnemen om een foutbericht aan te vragen als de aangevraagde versie van de CLR niet is gevonden. Standaard wordt het foutbericht niet weergegeven. (De De methode ICLRMetaHost::GetRuntime accepteert deze vlag niet en biedt geen andere manier om het foutbericht weer te geven.)
Windows biedt een SetErrorMode-functie die u kunt gebruiken om te declareren of u wilt dat foutberichten worden weergegeven als gevolg van code die binnen uw proces wordt uitgevoerd. U kunt de vlag SEM_FAILCRITICALERRORS opgeven om te voorkomen dat het foutbericht wordt weergegeven.
In sommige scenario's is het echter belangrijk om de SEM_FAILCRITICALERRORS instelling te overschrijven die is ingesteld door een toepassingsproces. Als u bijvoorbeeld een systeemeigen COM-onderdeel hebt dat als host fungeert voor de CLR en die wordt gehost in een proces waarin SEM_FAILCRITICALERRORS is ingesteld, kunt u de vlag overschrijven, afhankelijk van de impact van het weergeven van foutberichten binnen dat specifieke toepassingsproces. In dit geval kunt u een van de volgende vlaggen gebruiken om SEM_FAILCRITICALERRORS te overschrijven:
Gebruik METAHOST_POLICY_IGNORE_ERROR_MODE met de methode ICLRMetaHostPolicy::GetRequestedRuntime .
Gebruik RUNTIME_INFO_IGNORE_ERROR_MODE met de functie GetRequestedRuntimeInfo .
UI-beleid voor door CLR geleverde hosts
De CLR bevat een set hosts voor verschillende scenario's en deze hosts geven allemaal een foutbericht weer wanneer ze problemen ondervinden bij het laden van de vereiste versie van de runtime. De volgende tabel bevat een lijst met hosts en het bijbehorende foutberichtsbeleid.
CLR-host | Beschrijving | Beleid voor foutberichten | Kan het foutbericht worden uitgeschakeld? |
---|---|---|---|
Beheerde EXE-host | Start beheerde EXE's. | Wordt weergegeven in het geval van een ontbrekende .NET Framework-versie | Nee |
Beheerde COM-host | Laadt beheerde COM-onderdelen in een proces. | Wordt weergegeven in het geval van een ontbrekende .NET Framework-versie | Ja, door de vlag SEM_FAILCRITICALERRORS in te stellen |
ClickOnce-host | Start ClickOnce-toepassingen. | Wordt weergegeven in het geval van een ontbrekende .NET Framework-versie, te beginnen met .NET Framework 4.5 | Nee |
XBAP-host | Hiermee start u WPF XBAP-toepassingen. | Wordt weergegeven in het geval van een ontbrekende .NET Framework-versie, te beginnen met .NET Framework 4.5 | Nee |
Gedrag en gebruikersinterface van Windows 8
Het CLR-activeringssysteem biedt hetzelfde gedrag en dezelfde gebruikersinterface in Windows 8 als in andere versies van het Windows-besturingssysteem, behalve wanneer er problemen optreden bij het laden van CLR 2.0. Windows 8 bevat .NET Framework 4.5, dat gebruikmaakt van CLR 4.5. Windows 8 bevat echter geen .NET Framework 2.0, 3.0 of 3.5, die allemaal CLR 2.0 gebruiken. Als gevolg hiervan worden toepassingen die afhankelijk zijn van CLR 2.0 niet standaard uitgevoerd op Windows 8. In plaats daarvan wordt het volgende dialoogvenster weergegeven om gebruikers in staat te stellen .NET Framework 3.5 te installeren. Gebruikers kunnen .NET Framework 3.5 ook inschakelen in Configuratiescherm. Beide opties worden besproken in het artikel .NET Framework 3.5 installeren op Windows 11, Windows 10, Windows 8.1 en Windows 8.
Notitie
.NET Framework 4.5 vervangt .NET Framework 4 (CLR 4) op de computer van de gebruiker. Daarom worden .NET Framework 4-toepassingen naadloos uitgevoerd zonder dit dialoogvenster weer te geven in Windows 8.
Wanneer .NET Framework 3.5 is geïnstalleerd, kunnen gebruikers toepassingen uitvoeren die afhankelijk zijn van .NET Framework 2.0, 3.0 of 3.5 op hun Windows 8-computers. Ze kunnen ook .NET Framework 1.0- en 1.1-toepassingen uitvoeren, mits deze toepassingen niet expliciet zijn geconfigureerd om alleen te worden uitgevoerd op .NET Framework 1.0 of 1.1. Zie Migreren vanuit .NET Framework 1.1.
Vanaf .NET Framework 4.5 is de registratie van CLR-activering verbeterd met logboekvermeldingen die registreren wanneer en waarom het initialisatiefoutbericht wordt weergegeven. Zie Procedures voor meer informatie: Problemen met het opsporen van CLR-activeringsproblemen.