Fichiers de configuration d'activation

Une application qui fournit un modèle d'extensibilité managé peut imposer l'utilisation d'une version particulière du runtime .NET Framework pour le fonctionnement des extensions (en spécifiant cette version dans un fichier de configuration d'application ou un fichier de configuration d'hôte). Avant .NET Framework version 4, la seule façon d'écrire des extensions avec une version ultérieure du runtime consistait à fournir un fichier de configuration différent pour l'application. Malheureusement, cette solution avait l'inconvénient d'obliger toutes les extensions à utiliser le runtime le plus récent.

Les fichiers de configuration d'activation offrent une alternative dans le cas précis où l'auteur d'une extension utilise le modèle d'extensibilité d'une application en tant que plateforme et contrôle intégralement toutes les extensions chargées. Dans ce scénario, l'auteur de l'extension peut raisonnablement décider quelle version du runtime doit être chargée et activée.

Par exemple, .NET Framework 4 vous permet de créer un jeu de composants logiciels enfichables MMC (Microsoft Management Console) pour personnaliser l'interface utilisateur d'une console de gestion, sur des ordinateurs où MMC spécifie l'activation du runtime .NET Framework version 2.0. Vous ne pouvez pas remplacer directement les informations d'activation pour MMC, mais vous pouvez utiliser une variable d'environnement pour spécifier l'emplacement d'un fichier de configuration d'activation qui se substitue à elle pour une console particulière, afin que le runtime .NET Framework 4 soit activé lorsque la console est lancée.

Fourniture d'un fichier de configuration d'activation

Les noms de fichiers de configuration d'activation suivent le même modèle que les noms de fichiers de configuration d'application, mais ils utilisent l'extension .activation_config. Par exemple, une application nommée MonAppli.exe a un fichier de configuration d'application nommé MonAppli.exe.config et un fichier de configuration d'activation nommé MonAppli.exe.activation_config.

Les fichiers de configuration d'activation peuvent contenir n'importe quel élément de fichier de configuration, mais les seuls éléments analysés sont ceux utilisés normalement pour l'activation :

• Éléments dans la section <startup>.

• Éléments <gcServer>, <appdomainResourceMonitoring> et <etwEnable> dans la section <runtime>.

  Important
  Vérifiez que ces trois paramètres <runtime> dans le fichier de configuration d'activation sont les mêmes que les paramètres correspondants dans le fichier de configuration de l'application ou de l'hôte.

Le fichier de configuration d'activation est utilisé uniquement par le code shim qui démarre le runtime. Le runtime lui-même n'a aucune interaction avec le fichier.

Une fois que vous avez créé le fichier de configuration de l'application, affectez à la variable d'environnement COMPLUS_ApplicationMigrationRuntimeActivationConfigPath le chemin d'accès où se trouve le fichier. Lors de la sélection du runtime à activer, une recherche est effectuée dans le chemin d'accès pour trouver un fichier de configuration d'application dont le nom correspond au modèle.

Si la variable d'environnement est définie mais que le chemin d'accès spécifié ne contient aucun fichier de configuration d'activation correspondant au modèle, l'activation du runtime est contrôlée normalement par le fichier de configuration de l'application ou de l'hôte.

La variable d'environnement peut être définie de façon globale ou par un lanceur qui configure l'environnement. Les définitions de variables d'environnement globales sont soumises aux conditions de concurrence avec d'autres applications.

Par exemple, la session de ligne de commande suivante copie un fichier de configuration d'activation dans un dossier, affecte ce chemin d'accès à la variable d'environnement et exécute l'application :

copy c:\MyConfigs\MyApp.exe.activation_config c:\CustomConfigs
set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath =
   c:\CustomConfigs
c:\Program Files\MyApp\MyApp.exe

Le fichier de configuration d'activation suivant spécifie l'activation du runtime .NET Framework 4 et duplique un paramètre <appDomainResourceMonitoring> hypothétique à partir du fichier de configuration de l'application hypothétique :

<configuration>
   <startup>
      <supportedRuntime version="v4.0.xxxx"/>
   </startup>
   <runtime>
      <appDomainResourceMonitoring enabled="true"/>
   </runtime>
</configuration>

Méthodes d'activation prises en charge

Les fichiers de configuration d'activation affectent les méthodes d'activation suivantes. Le terme « hérité » fait référence aux versions du .NET Framework antérieures à .NET Framework 4.

• Exécution d'un fichier .exe managé sur un ordinateur où .NET Framework 4 est installé.

• Utilisation de l'API d'hébergement héritée ; par exemple, la fonction globale CorBindToRuntimeHost.

• Chargement et exécution de composants hérités en mode mixe créés avec Visual C++.

• Chargement et exécution de composants COM hérités.

  Remarque
  Les fichiers de configuration d'activation ne sont pas utilisés lorsque vous chargez et exécutez des composants COM créés à l'aide de .NET Framework 4 ou une version ultérieure.

• Utilisation de la méthode ICLRMetaHostPolicy::GetRequestedRuntime dans l'API d'hébergement avec l'indicateur METAHOST_POLICY_USE_PROCESS_IMAGE_PATH.

• Utilisation de la méthode ICLRMetaHostPolicy::GetRequestedRuntime et fourniture d'un chemin d'accès de fichier d'assembly pour le paramètre pwzBinary.

  Remarque
  Les fichiers de configuration d'activation ne sont pas utilisés si la méthode ICLRMetaHostPolicy::GetRequestedRuntime est appelée et que ni le paramètre pwzBinary ni l'indicateur METAHOST_POLICY_USE_PROCESS_IMAGE_PATH n'est utilisé.

Voir aussi

Concepts

Déploiement d'applications et du .NET Framework

Autres ressources

Hébergement (Référence des API non managées)