Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Cet article est spécifique à .NET Framework. Elle ne s’applique pas aux implémentations plus récentes de .NET, notamment .NET 6 et versions ultérieures.
Le système d’activation CLR (Common Language Runtime) détermine la version du CLR qui sera utilisée pour exécuter du code d’application managée. Dans certains cas, le système d’activation peut ne pas être en mesure de trouver une version du CLR à charger. Cette situation se produit généralement lorsqu’une application nécessite une version CLR non valide ou non installée sur un ordinateur donné. Si la version demandée est introuvable, le système d’activation CLR retourne un code d’erreur HRESULT à partir de la fonction ou de l’interface appelée et peut afficher un message d’erreur à l’utilisateur qui exécute l’application. Cet article fournit la liste des codes HRESULT et explique comment vous pouvez empêcher l’affichage du message d’erreur.
Le CLR fournit une infrastructure de journalisation pour vous aider à déboguer les problèmes d’activation CLR, comme décrit dans Comment : Déboguer les problèmes d'activation du CLR. Cette infrastructure ne doit pas être confondue avec les journaux de liaisons d'assemblage, qui sont entièrement différents.
Codes HRESULT d’activation du CLR
Les API d’activation CLR retournent des codes HRESULT pour signaler le résultat d’une opération d’activation à un hôte. Les hôtes CLR doivent toujours consulter ces valeurs de retour avant de poursuivre d’autres opérations.
CLR_E_SHIM_RUNTIMELOAD
CLR_E_SHIM_RUNTIMEEXPORT
CLR_E_SHIM_INSTALLROOT
CLR_E_SHIM_INSTALLCOMP (Erreur d'installation du composant Shim)
CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND
CLR_E_SHIM_SHUTDOWNINPROGRESS
Interface utilisateur pour les erreurs d’initialisation
Si le système d’activation CLR ne peut pas charger la version correcte du runtime requis par une application, il affiche un message d’erreur aux utilisateurs pour leur informer que leur ordinateur n’est pas correctement configuré pour exécuter l’application et leur donne la possibilité de remédier à la situation. Le message d’erreur suivant est généralement présenté dans cette situation. L’utilisateur peut choisir Oui pour accéder à un site web Microsoft où il peut télécharger la version correcte du .NET Framework pour l’application.
Résolution de l’erreur d’initialisation
En tant que développeur, vous disposez d’une variété d’options pour contrôler le message d’erreur d’initialisation du .NET Framework. Par exemple, vous pouvez utiliser un indicateur d’API pour empêcher l’affichage du message, comme indiqué dans la section suivante. Toutefois, vous devez toujours résoudre le problème qui empêchait votre application de charger le runtime demandé. Sinon, votre application peut ne pas s’exécuter du tout, ou certaines fonctionnalités peuvent ne pas être disponibles.
Pour résoudre les problèmes sous-jacents et fournir la meilleure expérience utilisateur (moins de messages d’erreur), nous vous recommandons les éléments suivants :
Pour les applications .NET Framework 3.5 (et versions antérieures) : configurez votre application pour prendre en charge .NET Framework 4 ou versions ultérieures (consultez les instructions).
Pour les applications .NET Framework 4 : installez le package redistribuable .NET Framework 4 dans le cadre de la configuration de votre application. Consultez le Guide de déploiement pour les développeurs.
Contrôle du message d’erreur
L’affichage d’un message d’erreur pour communiquer qu’une version de .NET Framework demandée n’a pas été trouvée peut être affichée comme un service utile ou une gêne mineure pour les utilisateurs. Dans les deux cas, vous pouvez contrôler cette interface utilisateur en passant des indicateurs aux API d’activation.
La méthode ICLRMetaHostPolicy ::GetRequestedRuntime accepte un membre d’énumération METAHOST_POLICY_FLAGS comme entrée. Vous pouvez inclure l’indicateur METAHOST_POLICY_SHOW_ERROR_DIALOG pour demander un message d’erreur si la version demandée du CLR est introuvable. Par défaut, le message d’erreur n’est pas affiché. (La méthode ICLRMetaHost ::GetRuntime n’accepte pas cet indicateur et ne fournit aucun autre moyen d’afficher le message d’erreur.)
Windows fournit une fonction SetErrorMode que vous pouvez utiliser pour déclarer si vous souhaitez que les messages d’erreur soient affichés à la suite du code qui s’exécute dans votre processus. Vous pouvez spécifier l’indicateur SEM_FAILCRITICALERRORS pour empêcher l’affichage du message d’erreur.
Toutefois, dans certains scénarios, il est important de remplacer le paramètre SEM_FAILCRITICALERRORS défini par un processus d’application. Par exemple, si vous avez un composant COM natif qui héberge le CLR et qui est hébergé dans un processus où SEM_FAILCRITICALERRORS est défini, vous pouvez remplacer l’indicateur, en fonction de l’impact de l’affichage des messages d’erreur au sein de ce processus d’application particulier. Dans ce cas, vous pouvez utiliser l’un des indicateurs suivants pour remplacer SEM_FAILCRITICALERRORS :
Utilisez METAHOST_POLICY_IGNORE_ERROR_MODE avec la méthode ICLRMetaHostPolicy ::GetRequestedRuntime .
Utilisez RUNTIME_INFO_IGNORE_ERROR_MODE avec la fonction GetRequestedRuntimeInfo .
Stratégie d’interface utilisateur pour les hôtes fournis par CLR
Le CLR inclut un ensemble d’hôtes pour divers scénarios, et ces hôtes affichent tous un message d’erreur lorsqu’ils rencontrent des problèmes lors du chargement de la version requise du runtime. Le tableau suivant fournit la liste des hôtes et leurs stratégies de message d’erreur.
| Hôte CLR | Descriptif | Stratégie de message d’erreur | Le message d’erreur peut-il être désactivé ? |
|---|---|---|---|
| Hôte EXE managé | Lance des EXE managés. | S’affiche dans le cas d’une version manquante du .NET Framework | Non |
| Hôte COM managé | Charge des composants COM managés dans un processus. | S’affiche dans le cas d’une version manquante du .NET Framework | Oui, en définissant le flag SEM_FAILCRITICALERRORS |
| Serveur ClickOnce | Lance des applications ClickOnce. | S’affiche dans le cas d’une version .NET Framework manquante, en commençant par .NET Framework 4.5 | Non |
| Hôte XBAP | Lance des applications WPF XBAP. | S’affiche dans le cas d’une version .NET Framework manquante, en commençant par .NET Framework 4.5 | Non |
Comportement et interface utilisateur de Windows 8
Le système d’activation CLR fournit le même comportement et l’interface utilisateur sur Windows 8 que sur d’autres versions du système d’exploitation Windows, sauf lorsqu’il rencontre des problèmes de chargement du CLR 2.0. Windows 8 inclut .NET Framework 4.5, qui utilise CLR 4.5. Toutefois, Windows 8 n’inclut pas .NET Framework 2.0, 3.0 ou 3.5, qui utilisent tous CLR 2.0. Par conséquent, les applications qui dépendent du CLR 2.0 ne s’exécutent pas sur Windows 8 par défaut. Au lieu de cela, ils affichent la boîte de dialogue suivante pour permettre aux utilisateurs d’installer .NET Framework 3.5. Les utilisateurs peuvent également activer .NET Framework 3.5 dans le Panneau de configuration. Les deux options sont abordées dans l’article Installer .NET Framework 3.5 sur Windows 11, Windows 10, Windows 8.1 et Windows 8.
Remarque
.NET Framework 4.5 remplace le .NET Framework 4 (CLR 4) sur l’ordinateur de l’utilisateur. Par conséquent, les applications .NET Framework 4 s’exécutent en toute transparence, sans afficher cette boîte de dialogue, sur Windows 8.
Lorsque .NET Framework 3.5 est installé, les utilisateurs peuvent exécuter des applications qui dépendent de .NET Framework 2.0, 3.0 ou 3.5 sur leurs ordinateurs Windows 8. Ils peuvent également exécuter des applications .NET Framework 1.0 et 1.1, à condition que ces applications ne soient pas explicitement configurées pour s’exécuter uniquement sur .NET Framework 1.0 ou 1.1. Consultez Migration à partir du .NET Framework 1.1.
À compter de .NET Framework 4.5, la journalisation de l’activation clR a été améliorée pour inclure les entrées de journal qui enregistrent quand et pourquoi le message d’erreur d’initialisation s’affiche. Pour plus d’informations, consultez Guide pratique pour déboguer les problèmes d’activation du CLR.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
