Vue d'ensemble de l'hébergement
Les applications .NET Framework hébergent automatiquement le Common Language Runtime avec lequel elles ont été générées. Si vous compilez votre code managé en tant qu'assembly .exe, le runtime est automatiquement démarré par mscoree.dll lorsque le fichier .exe est exécuté. Les applications non managées peuvent également bénéficier de l'hébergement du Common Language Runtime. Le runtime fournit une infrastructure permettant d'étendre les applications telles que Microsoft Internet Information Services (IIS) et Microsoft SQL Server 2005.
Qu'une application .NET Framework soit appelée automatiquement, comme avec les assemblys .exe managés, ou chargée à l'aide de l'API d'hébergement non managé, elle requiert un fragment de code appelé hôte de runtime. L'hôte de runtime charge le runtime dans un processus, crée des domaines d'application dans le processus et charge et exécute le code utilisateur dans ces domaines d'application.
.NET Framework version 2.0 propose des applications qui hébergent le CLR pour contrôler de nombreuses fonctionnalités du runtime. Vous pouvez remplacer certaines fonctionnalités, telles que l'allocation de mémoire et le chargement d'assembly, par des implémentations personnalisées. Vous pouvez contrôler le comportement d'autres fonctionnalités, recevoir des notifications d'événements dans le runtime et gérer des domaines d'application.
Le .NET Framework version 4 consolide la plupart des API d'hébergement de la version 2.0. De plus, le .NET Framework 4 prend en charge l'activation de l'hôte du runtime côte à côte in-process et fournit d'autres améliorations.
Cette vue d'ensemble contient les sections suivantes :
Initialisation et démarrage d'un runtime hébergé
Interfaces de gestion d'hébergement .NET Framework version 2.0
Interfaces de gestion d'hébergement .NET Framework version 4
Gestionnaires de domaine d'application
Rubriques connexes
Référence
Initialisation et démarrage d'un runtime hébergé
L'API d'hébergement du .NET Framework 4 fournit la fonction CLRCreateInstance, qui peut retourner l'interface ICLRMetaHost. Vous pouvez ensuite appeler la méthode GetRuntime sur cette interface pour obtenir une interface ICLRRuntimeInfo spécifique, selon une version particulière du CLR. Cette procédure remplace la méthode CorBindToRuntimeEx utilisée par l'API d'hébergement .NET Framework 2.0.
L'API d'hébergement .NET Framework version 2.0 fournit la fonction CorBindToRuntimeEx pour initialiser le runtime. Vous pouvez choisir la version du runtime à charger, mais un processus ne peut héberger qu'une seule version. Si la version 2.0, 3.0 ou 3.5 est chargée, la fonction retourne l'interface ICLRRuntimeHost, qui est utilisée pour démarrer le runtime et exécuter du code managé.
L'API d'hébergement .NET Framework version 1 fournit l'interface ICorRuntimeHost.
Le démarrage du runtime est traité dans Chargement du Common Language Runtime dans un processus et l'exécution du code managé est traitée dans Transition vers un code d'hébergement managé.
Retour au début
Interfaces de gestion d'hébergement .NET Framework 2.0
Dans .NET Framework 2.0, le CLR fournit des interfaces de gestion d'hébergement pour contrôler de nombreuses fonctionnalités du runtime hébergé, permet à l'application hôte d'implémenter d'autres interfaces de gestion fournies par le runtime et vous permet d'implémenter vos propres interfaces de gestion d'hébergement.
À titre d'information, les interface de gestion peuvent être classées en deux grandes catégories :
Interfaces de gestion que l'hôte implémente et que le runtime découvre via l'interface IHostControl.
Interfaces de gestion que le CLR fournit et que l'hôte découvre via l'interface ICLRControl.
Le tableau suivant regroupe les interfaces selon le type de fonctionnalités qu'elles fournissent. L'interface la plus importante au sein de chaque groupe figure en premier.
Groupe |
Fonction |
Interfaces |
|---|---|---|
Gestion du chargement d'assembly |
Permet à l'hôte de personnaliser les emplacements à partir desquels les assemblys sont chargés, la façon dont les versions sont gérées et les formats dans lesquels les assemblys peuvent être chargés. Par exemple, les assemblys peuvent être chargés à partir d'une base de données plutôt qu'à partir de fichiers sur le disque dur. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion de la stratégie |
Permet à l'hôte de spécifier le mode de traitement des échecs d'un programme et de prendre en charge les différentes exigences de fiabilité. L'hôte utilise l'interface ICLRControl pour accéder au gestionnaire du runtime et implémente des rappels IHostPolicyManager pour les notifications d'échec provenant du runtime. |
|
Gestion de la protection de l'hôte |
Permet à l'hôte d'appliquer son propre modèle de programmation en empêchant l'utilisation de types ou membres spécifiés. Par exemple, l'hôte peut interdire l'utilisation de primitives de synchronisation ou de thread. L'hôte utilise l'interface ICLRControl pour accéder au gestionnaire du runtime. |
|
Gestion de la mémoire |
Permet à l'hôte de contrôler l'allocation de mémoire en fournissant des remplacements pour les fonctions du système d'exploitation que le CLR utilise pour allouer de la mémoire. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion du garbage collection |
Permet à l'hôte d'implémenter des méthodes pour recevoir la notification du début et de la fin d'un garbage collection. Permet à l'hôte d'initier des collections, de collecter des statistiques et de spécifier certaines caractéristiques de collection. L'hôte utilise l'interface ICLRControl pour accéder au gestionnaire du runtime. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion du débogage |
Permet à l'hôte de déterminer si un débogueur est attaché, de fournir des informations de débogage supplémentaires et de personnaliser des tâches de débogage. L'hôte utilise l'interface ICLRControl pour accéder au gestionnaire du runtime. |
|
Gestion des événements du CLR |
Permet à un hôte de s'enregistrer pour la notification des événements énumérés par EClrEvent. L'hôte fait appel à l'interface ICLRControl pour accéder au gestionnaire du runtime et implémente ses gestionnaires d'événements en utilisant l'interface IActionOnCLREvent. |
|
Gestion des tâches |
Permet à l'hôte d'être notifié chaque fois qu'un thread effectue une transition entre le code managé et non managé. Permet à l'hôte de contrôler l'affinité de thread, lorsque des tâches sont démarrées et arrêtées, ainsi que la manière dont elles sont planifiées. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion du pool de threads |
Permet à l'hôte d'implémenter son propre pool de threads en vue d'une utilisation par le runtime. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion de la synchronisation |
Permet à l'hôte d'implémenter ses propres primitives de synchronisation en vue d'une utilisation par le runtime. L'hôte peut fournir des événements, des sections critiques et des sémaphores. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
|
Gestion de terminaison d'E/S |
Permet à l'hôte d'effectuer sa propre implémentation d'entrée/sortie asynchrone. Le CLR utilise l'interface IHostControl pour déterminer si un hôte implémente ce groupe d'interfaces. |
.gif "Remarque") Remarque |
|---|
Les interfaces d'hébergement pour les précédentes versions du runtime sont documentées dans Interfaces de gestion d'hébergement de .NET Framework 1.0 et 1.1. |
Retour au début
Interfaces de gestion d'hébergement .NET Framework 4
.NET Framework 4 consolide l'API d'hébergement 2.0 dans les interfaces suivantes :
ICLRMetaHost fournit des méthodes qui retournent une version spécifique du CLR, répertorient tous les CLR installés, listent tous les runtimes in-process, retournent l'interface d'activation et trouvent la version du CLR utilisée pour compiler un assembly.
ICLRMetaHostPolicy fournit la méthode GetRequestedRuntime qui offre une interface CLR selon un critère de stratégie, l'assembly managé, la version et le fichier de configuration.
ICLRRuntimeInfo fournit des méthodes qui retournent des informations sur un runtime spécifique, notamment la version, le répertoire et l'état de charge.
ICLRStrongName regroupe l'ensemble des fonctions statiques globales d'utilisation de noms forts du CLR version 2.0 qui sont exportées par MSCorEE.dll (sauf StrongNameErrorInfo) vers une interface unique. Toutes les méthodes ICLRStrongName retournent des valeurs HRESULT COM standard.
Ces interfaces encapsulent et remplacent les interfaces d'hébergement .NET Framework 2.0.
Retour au début
Gestionnaires de domaine d'application
Pour les programmes qui hébergent le Common Language Runtime, les domaines d'application offrent une plus grande fiabilité en séparant les assemblys les uns des autres. Les assemblys peuvent être déchargés du processus via le déchargement de domaines d'application.
Pour gérer plusieurs domaines d'application, le .NET Framework fournit la classe AppDomainManager comme classe de base de laquelle vous pouvez dériver vos propres gestionnaires de domaine d'application. Le gestionnaire de domaine d'application que vous concevez pour votre application hôte est essentiellement une extension de l'hôte, en code managé. Il est automatiquement chargé dans chaque domaine d'application créé dans votre processus.
Le gestionnaire de domaine d'application peut améliorer les performances en éliminant certaines transitions entre le code managé et non managé. Il peut recevoir une notification de création de nouveaux domaines d'application, ce qui vous donne la possibilité de les configurer. Le gestionnaire de domaine d'application permet également à un hôte non managé d'appeler du code managé.
Retour au début
Rubriques connexes
Titre |
Description |
|---|---|
Décrit comment charger le runtime dans un processus, l'initialiser et définir des valeurs pour spécifier son comportement. |
|
Décrit comment décharger des domaines d'application et arrêter un processus. |
|
Définition d'entités de sécurité et d'une stratégie de sécurité basées sur les rôles |
Décrit comment définir une stratégie de sécurité basée sur les rôles. |
Définition d'une stratégie de sécurité au niveau du domaine d'application |
Décrit comment définir une stratégie de sécurité au niveau du domaine d'application. |
Décrit comment charger et exécuter le code utilisateur. |
|
Décrit comment créer et configurer des domaines d'application dans lesquels exécuter le code utilisateur. |
|
Décrit comment déterminer l'emplacement des limites d'un nouveau domaine d'application. |
|
Décrit comment effectuer la transition de code non managé pour exécuter le code d'hébergement managé et le code utilisateur. |
|
Décrit comment activer une version du runtime autre que celle spécifiée dans le fichier de configuration de l'application. |
|
Décrit les hôtes inclus avec le .NET Framework. |
|
Décrit les constructions que les hôtes utilisent pour isoler le code s'exécutant dans un processus. |
|
Décrit l'exécution de plusieurs versions d'une application, d'un composant ou du runtime. |
|
Décrit les interfaces non managées pour l'hébergement du runtime dans .NET Framework version 4. |
|
Décrit les interfaces non managées pour l'hébergement du runtime dans .NET Framework version 2.0. |
Retour au début
Référence
Retour au début