Fehler beim Initialisieren von .NET Framework: Verwalten der Benutzerfreundlichkeit

  • Artikel

Das Aktivierungssystem der CLR (Common Language Runtime) bestimmt die Version der CLR, die verwendet wird, um verwalteten Anwendungscode auszuführen. In einigen Fällen ist das Aktivierungssystem eventuell nicht in der Lage, eine Version der CLR zu suchen und zu laden. Diese Situation tritt in der Regel auf, wenn eine Anwendung eine CLR-Version erfordert, die ungültig oder nicht auf einem Computer installiert ist. Wenn die angeforderte Version nicht gefunden wird, gibt das CLR-Aktivierungssystem einen HRESULT-Fehlercode von der aufgerufenen Funktion oder Schnittstelle zurück und zeigt dem Benutzer, der die Anwendung ausführt, eventuell eine Fehlermeldung an. Dieser Artikel enthält eine Liste von HRESULT-Codes und beschreibt, wie Sie die Anzeige der Fehlermeldung verhindern können.

Die CLR stellt die Protokollierungsinfrastruktur bereit, die Ihnen helfen wird, CLR-Aktivierungsprobleme zu debuggen. Diese Vorgehensweise wird im Artikel How to Debug CLR Activation Issues (Debuggen von CLR-Aktivierungsproblemen) beschrieben. Die Infrastruktur darf nicht mit Assemblybindungsprotokollen verwechselt werden. Bei diesen handelt es sich um einen vollständig anderen Protokolltyp.

CLR-Aktivierungscodes (HRESULT)

Die CLR-Aktivierung APIs geben HRESULT-Code zurück, um das Ergebnis einer Aktivierung an einen Host zu melden. CLR-Hosts sollten diese Rückgabewerte immer nachschlagen, bevor sie zusätzliche Vorgängen fortsetzen.

  • CLR_E_SHIM_RUNTIMELOAD

  • CLR_E_SHIM_RUNTIMEEXPORT

  • CLR_E_SHIM_INSTALLROOT

  • CLR_E_SHIM_INSTALLCOMP

  • CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND

  • CLR_E_SHIM_SHUTDOWNINPROGRESS

Benutzeroberfläche für Initialisierungsfehler

Wenn das CLR-Aktivierungssystem die richtige Version der Laufzeit, die von einer Anwendung benötigt wird, nicht laden kann, wird eine Fehlermeldung angezeigt. Diese informiert den Benutzer darüber, dass der Computer für das Ausführen der Anwendung nicht ordnungsgemäß konfiguriert ist, und bietet eine Möglichkeit, die Situation zu beheben. In dieser Situation wird in der Regel die folgende Fehlermeldung erstellt. Der Benutzer kann Ja wählen, um zu einer Microsoft-Website zu wechseln, auf der die richtige .NET Framework-Version für die Anwendung heruntergeladen werden kann.

.NET Framework Initialization Error dialog box

Beheben von Initialisierungsfehlern

Als Entwickler haben Sie eine Vielzahl von Optionen, um die .NET Framework-Initialisierungsfehlermeldung zu steuern. Beispielsweise können Sie ein API-Flag verwenden, um die Anzeige der Meldung zu verhindern. Dies wird im nächsten Abschnitt erläutert. Sie müssen jedoch noch das Problem beheben, das die Anwendung am Laden der angeforderten Laufzeit hindert. Andernfalls wird die Anwendung möglicherweise gar nicht ausgeführt, oder eine bestimmte Funktion ist eventuell nicht verfügbar.

Um das zugrunde liegende Problem zu beheben und die beste Benutzerfreundlichkeit (weniger Fehlermeldungen) bereitzustellen, empfehlen wir Folgendes:

  • Für Anwendungen, die auf .NET Framework 3.5 und früher basieren: Konfigurieren Sie Ihre Anwendung so, dass sie .NET Framework 4 oder höher unterstützt. Weitere Informationen finden Sie in dieser Anleitung.

  • Für Anwendungen, die auf .NET Framework 4 basieren: Installieren Sie das verteilbare. .NET Framework 4-Paket während des Setups der Anwendung. Weitere Informationen finden Sie unter Bereitstellungshandbuch für Entwickler.

Steuerung von Fehlermeldungen

Das Anzeigen einer Fehlermeldung, die kommuniziert, dass eine angeforderte .NET Framework-Version nicht gefunden wurde, kann entweder als ein hilfreicher Dienst oder ein kleines Ärgernis für den Benutzer angesehen werden. In beiden Fällen können Sie diese Benutzeroberfläche steuern, indem Sie Flags an die Aktivierung-API übergeben.

Die ICLRMetaHostPolicy::GetRequestedRuntime-Methode akzeptiert einen METAHOST_POLICY_FLAGS-Enumerationsmember als Eingabe. Sie können das METAHOST_POLICY_SHOW_ERROR_DIALOG-Flag einschließen, um eine Fehlermeldung anzufordern, wenn die angeforderte Version der CLR nicht gefunden wird. Standardmäßig wird die Fehlermeldung nicht angezeigt. (Die ICLRMetaHost::GetRuntime-Methode akzeptiert dieses Flag nicht und stellt keine andere Möglichkeit bereit, um die Fehlermeldung anzuzeigen.)

Windows bietet eine SetErrorMode-Funktion, die Sie verwenden können, um zu deklarieren, dass Sie Fehlermeldungen aufgrund des innerhalb des Prozesses ausgeführten Codes angezeigt werden soll. Sie können das SEM_FAILCRITICALERRORS-Flag angeben, um das Anzeigen der Fehlermeldung zu verhindern.

In einigen Szenarios ist es wichtig, die SEM_FAILCRITICALERRORS-Einstellung zu überschreiben, die von einem Anwendungsprozess festgelegt wurde. Wenn Sie beispielsweise über eine systemeigene COM-Komponente verfügen, die die CLR hostet und in einem Prozess gehostet wird, in dem SEM_FAILCRITICALERRORS festgelegt ist, können Sie das Flag in Abhängigkeit von den Auswirkungen der Anzeige von Fehlermeldungen in diesem bestimmten Prozess überschreiben. In diesem Fall können Sie eines der folgenden Flags verwenden, um SEM_FAILCRITICALERRORS zu überschreiben:

Benutzeroberflächenrichtlinie für von der CLR bereitgestellte Hosts

Die CLR bietet eine Reihe von Hosts für verschiedene Szenarien, und alle diese Hosts zeigen eine Fehlermeldung an, wenn Probleme beim Laden der erforderlichen Laufzeitversion auftreten. Die folgende Tabelle enthält eine Liste von Hosts und deren Fehlermeldungsrichtlinien.

CLR-Host Beschreibung Fehlermeldungsrichtlinie Kann die Fehlermeldung deaktiviert werden?
Verwalteter EXE-Host Startet verwaltete EXE-Dateien. Wird im Fall von fehlender .NET Framework-Version angezeigt Nein
Verwalteter COM-Host Lädt verwalteten COM-Komponenten in einen Prozess. Wird im Fall von fehlender .NET Framework-Version angezeigt Ja, durch Festlegen des SEM_FAILCRITICALERRORS-Flags
ClickOnce-Host Startet ClickOnce-Anwendungen. Wird ab .NET Framework 4.5 im Fall einer fehlenden .NET Framework-Version angezeigt Nein
XBAP-Host Startet WPF-XBAP-Anwendungen. Wird ab .NET Framework 4.5 im Fall einer fehlenden .NET Framework-Version angezeigt Nein

Verhalten und Benutzeroberfläche von Windows 8

Das CLR-Aktivierungssystem stellt das gleiche Verhalten und die gleiche Benutzeroberfläche unter Windows 8 bereit, wie auf anderen Versionen des Windows-Betriebssystems, es sei denn, es treten Probleme beim Laden von CLR 2.0 auf. Windows 8 umfasst .NET Framework 4.5, das CLR 4.5 verwendet. Windows 8 umfasst jedoch nicht .NET Framework 2.0, 3.0 oder 3.5, die alle CLR 2.0 verwenden. Daher werden Anwendungen, die von CLR 2.0 abhängen, unter Windows 8 nicht standardmäßig ausgeführt. Stattdessen wird das folgende Dialogfeld angezeigt, um Benutzer*innen das Installieren von .NET Framework 3.5 zu ermöglichen. Benutzer können .NET Framework 3.5 auch in der Systemsteuerung aktivieren. Beide Optionen werden im Artikel Installieren von .NET Framework 3.5 unter Windows 11, Windows 10, Windows 8.1 und Windows 8 behandelt.

Dialog box for 3.5 install on Windows 8

Hinweis

.NET Framework 4.5 ersetzt .NET Framework 4 (CLR 4) auf dem Computer des Benutzers. Daher werden .NET Framework 4-Anwendungen nahtlos ausgeführt, ohne dieses Dialogfeld unter Windows 8 anzuzeigen.

Wenn .NET Framework 3.5 installiert ist, können Benutzer*innen Anwendungen, die .NET Framework 2.0, 3.0 oder 3.5 benötigen, auf ihren Computern unter Windows 8 ausführen. Sie können .NET Framework 1.0 und 1.1-Anwendungen ausführen, vorausgesetzt, dass diese Anwendungen nicht explizit so konfiguriert wurden, dass sie nur auf .NET Framework 1.0 oder 1.1 ausgeführt werden können. Weitere Informationen finden Sie unter Migrieren von .NET Framework 1.1.

Ab .NET Framework 4.5 wurde die CLR-Aktivierungsprotokollierung verbessert. Sie enthält nun auch Protokolleinträge, die erfassen, wann und warum eine Initialisierungsfehlermeldung angezeigt wird. Weitere Informationen finden Sie unter Vorgehensweise: Debuggen von CLR-Aktivierungsproblemen.

Siehe auch