Freigeben über

.NET Framework-Initialisierungsfehler: Verwalten der Benutzeroberfläche

Hinweis

Dieser Artikel ist spezifisch für .NET Framework. Sie gilt nicht für neuere Implementierungen von .NET, einschließlich .NET 6 und höherer Versionen.

Das Aktivierungssystem für die Common Language Runtime (CLR) bestimmt die Version der CLR, die zum Ausführen von verwaltetem Anwendungscode verwendet wird. In einigen Fällen kann das Aktivierungssystem möglicherweise keine zu ladende Version der CLR finden. Diese Situation tritt in der Regel auf, wenn eine Anwendung eine CLR-Version erfordert, die auf einem bestimmten Computer ungültig oder nicht installiert ist. Wenn die angeforderte Version nicht gefunden wird, gibt das CLR-Aktivierungssystem einen HRESULT-Fehlercode aus der aufgerufenen Funktion oder Schnittstelle zurück und zeigt dem Benutzer, der die Anwendung ausführt, möglicherweise eine Fehlermeldung an. Dieser Artikel enthält eine Liste der HRESULT-Codes und erläutert, wie Sie verhindern können, dass die Fehlermeldung angezeigt wird.

Die CLR stellt die Protokollierungsinfrastruktur bereit, die Sie beim Debuggen von CLR-Aktivierungsproblemen unterstützt, wie in " How to: Debug CLR Activation Issues" beschrieben. Diese Infrastruktur sollte nicht mit Assemblybindungsprotokollen verwechselt werden, die völlig unterschiedlich sind.

CLR-Aktivierungscodes (HRESULT)

Die CLR-Aktivierungs-APIs geben HRESULT-Codes zurück, um das Ergebnis eines Aktivierungsvorgangs 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 benutzern eine Fehlermeldung angezeigt, um sie darüber zu informieren, dass ihr Computer nicht ordnungsgemäß für die Ausführung der Anwendung konfiguriert ist, und bietet ihnen die Möglichkeit, die Situation zu beheben. Die folgende Fehlermeldung wird in der Regel in dieser Situation angezeigt. Der Benutzer kann "Ja" auswählen, um zu einer Microsoft-Website zu wechseln, auf der er die richtige .NET Framework-Version für die Anwendung herunterladen kann.

.NET Framework Initialisierungsfehler (Dialogfeld

Beheben des Initialisierungsfehlers

Als Entwickler haben Sie eine Vielzahl von Optionen zum Steuern der .NET Framework-Initialisierungsfehlermeldung. Sie können z. B. ein API-Flag verwenden, um zu verhindern, dass die Nachricht angezeigt wird, wie im nächsten Abschnitt erläutert. Sie müssen das Problem jedoch weiterhin beheben, das verhindert hat, dass Ihre Anwendung die angeforderte Laufzeit lädt. Andernfalls wird Ihre Anwendung möglicherweise nicht ausgeführt, oder einige Funktionen sind möglicherweise nicht verfügbar.

Um die zugrunde liegenden Probleme zu beheben und die beste Benutzererfahrung (weniger Fehlermeldungen) bereitzustellen, empfehlen wir Folgendes:

  • Für .NET Framework 3.5 (und frühere) Anwendungen: Konfigurieren Sie Ihre Anwendung so, dass sie .NET Framework 4 oder höher unterstützt (siehe Anweisungen).

  • Für .NET Framework 4-Anwendungen: Installieren Sie das .NET Framework 4 weiterverteilbare Paket als Teil der Einrichtung Ihrer Anwendung. Siehe Bereitstellungshandbuch für Entwickler.

Steuern der Fehlermeldung

Wenn Eine Fehlermeldung angezeigt wird, um zu kommunizieren, dass eine angeforderte .NET Framework-Version nicht gefunden wurde, kann entweder als hilfreicher Dienst oder als geringfügige Verärrung für Benutzer angesehen werden. In beiden Fällen können Sie diese Benutzeroberfläche steuern, indem Sie Flags an die Aktivierungs-APIs übergeben.

Die ICLRMetaHostPolicy::GetRequestedRuntime-Methode akzeptiert ein METAHOST_POLICY_FLAGS Enumerationselement 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 bietet keine andere Möglichkeit, die Fehlermeldung anzuzeigen.)

Windows stellt eine SetErrorMode-Funktion bereit, mit der Sie deklarieren können, ob Fehlermeldungen als Ergebnis von Code angezeigt werden sollen, der in Ihrem Prozess ausgeführt wird. Sie können das Kennzeichen SEM_FAILCRITICALERRORS angeben, um zu verhindern, dass die Fehlermeldung angezeigt wird.

In einigen Szenarien ist es jedoch wichtig, die von einem Anwendungsprozess festgelegte SEM_FAILCRITICALERRORS Einstellung außer Kraft zu setzen. 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 außer Kraft zu setzen:

Benutzeroberflächenrichtlinie für vom CLR bereitgestellte Hosts

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

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

Windows 8-Verhalten und Benutzeroberfläche

Das CLR-Aktivierungssystem bietet das gleiche Verhalten und dieselbe Benutzeroberfläche unter Windows 8 wie in anderen Versionen des Windows-Betriebssystems, es sei denn, es treten Probleme beim Laden von CLR 2.0 auf. Windows 8 enthält .NET Framework 4.5, das CLR 4.5 verwendet. Windows 8 enthält 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, standardmäßig nicht unter Windows 8 ausgeführt. Stattdessen wird das folgende Dialogfeld angezeigt, um Benutzern die Installation 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 erläutert.

Dialogfeld für die Installation von 3.5 unter 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 Anwendungen ausführen, die von .NET Framework 2.0, 3.0 oder 3.5 auf ihren Windows 8-Computern abhängen. Sie können auch .NET Framework 1.0- und 1.1-Anwendungen ausführen, vorausgesetzt, diese Anwendungen sind nicht explizit so konfiguriert, dass sie nur auf .NET Framework 1.0 oder 1.1 ausgeführt werden. Siehe Migrieren von .NET Framework 1.1.

Ab .NET Framework 4.5 wurde die CLR-Aktivierungsprotokollierung verbessert, um Protokolleinträge einzuschließen, die aufzeichnen, wann und warum die Initialisierungsfehlermeldung angezeigt wird. Weitere Informationen finden Sie unter So debuggen Sie CLR-Aktivierungsprobleme.

Siehe auch