Redirection des versions d'assemblys
Mise à jour : novembre 2007
Si vous construisez une application .NET Framework sur base d'une version spécifique d'un assembly à nom fort, l'application utilise cette version de l'assembly au moment de l'exécution. Cependant, vous souhaitez peut-être que l'application s'exécute sur base d'une version plus récente d'un assembly. Un fichier de configuration de l'application, un fichier de configuration machine ou un fichier de stratégie d'éditeur peut rediriger une version d'un assembly vers une autre. Pour plus de détails sur la façon dont le Common Language Runtime utilise ces fichiers pour déterminer la version de l'assembly à utiliser, consultez la rubrique Méthode de localisation des assemblys par le runtime. Vous pouvez utiliser l'outil .NET Framework Configuration (Mscorcfg.msc) pour rediriger les versions d'assemblys, au niveau de l'application et de l'ordinateur, ou vous pouvez modifier le fichier de configuration.
.gif "Remarque") Remarque : |
|---|
Vous ne pouvez pas rediriger des versions d'assemblys qui ne portent pas un nom fort. Le Common Language Runtime ignore la version des assemblys qui ne portent pas un nom fort. |
Redirection des versions d'assemblys au moyen de la stratégie de l'éditeur
Les fournisseurs d'assemblys peuvent établir que les applications utilisent une nouvelle version en incluant un fichier de stratégie d'éditeur contenant l'assembly mis à jour. Le fichier de stratégie de l'éditeur, situé dans le Global Assembly Cache, contient les paramètres de redirection des assemblys.
Chaque version majeure.mineure d'un assembly possède son propre fichier de stratégie d'éditeur. Par exemple, les redirections de la version 1.1.2.222 à la version 1.1.3.000 et de la version 1.1.2.321 à la version 1.1.3.000 sont toutes deux placées dans le même fichier. En revanche, une redirection de la version 2.0.0.999 à la version 3.0.0.000 sera placée dans un fichier distinct.
Si un fichier de stratégie d'éditeur existe, le runtime vérifie ce fichier après le manifeste de l'assembly et le fichier de configuration de l'application. Les fournisseurs doivent utiliser les stratégies d'éditeur uniquement lorsque le nouvel assembly est compatible en amont avec l'assembly redirigé.
Vous pouvez ignorer la stratégie de l'éditeur en spécifiant certains paramètres du fichier de configuration de l'application.
Ignorer la stratégie d'éditeur
Les nouvelles versions d'assemblys compatibles en amont peuvent quand même bloquer une application. Lorsque ceci se produit, vous pouvez utiliser le paramètre suivant dans le fichier de configuration de l'application pour faire en sorte que le runtime ignore la stratégie d'éditeur:
<publisherPolicy apply="no" />
Ignorez la stratégie d'éditeur pour assurer le fonctionnement de votre application pour vos utilisateurs, mais veillez néanmoins à porter le problème à la connaissance du fournisseur de l'assembly. Si un assembly possède une stratégie d'éditeur, le fournisseur doit s'assurer qu'elle est compatible en amont et que les clients peuvent utiliser la nouvelle version autant que possible.
Redirection des versions d'assemblys au niveau de l'application
Supposons que le fournisseur de l'assembly publie une nouvelle version d'un assembly utilisé par votre application, mais ne fournit pas une stratégie d'éditeur parce que le fournisseur ne veut pas garantir que le nouvel assembly est compatible en amont avec la version d'origine. Vous pouvez spécifier que votre application utilise la nouvelle version de l'assembly en plaçant des informations de liaison dans le fichier de configuration de votre application.
Redirection des versions d'assemblys au niveau de l'ordinateur
Dans certains cas peu fréquents, l'administrateur de l'ordinateur peut souhaiter que toutes les applications de cet ordinateur utilisent une version spécifique d'un assembly. Par exemple, vous pourriez vouloir que toutes les applications utilisent une certaine version d'assembly parce qu'elle corrige une brèche de sécurité. Si un assembly est redirigé dans le fichier de configuration de l'ordinateur, toutes les applications utilisant l'ancienne version utiliseront la nouvelle version. Le fichier de configuration machine substitue le fichier de configuration de l'application et la stratégie de l'éditeur.
Spécification de la liaison d'assembly dans les fichiers de configuration
Le fichier de configuration de l'application, le fichier de configuration machine et le fichier de stratégie d'éditeur utilise le même schéma XML pour traiter la redirection de l'assembly.
Liaison d'assembly
Spécifiez les informations pour un assembly en les plaçant dans l'élément <dependentAssembly>. L'élément <assemblyIdentity> contient des informations qui identifient un assembly. Vous pouvez avoir plusieurs éléments <dependentAssembly> dans le fichier de configuration, mais il doit y avoir très exactement un élément <assemblyIdentity> dans chaque élément <dependentAssembly>.
Pour lier un assembly, vous devez spécifier la chaîne "urn:schemas-microsoft-com:asm.v1" avec l'attribut xmlns dans la balise <assemblyBinding>.
Spécification de la stratégie d'éditeur
Pour que le runtime ignore la stratégie d'éditeur pour un assembly particulier, placez l'élément <publisherPolicy> dans l'élément <dependentAssembly>. Pour que le runtime ignore la stratégie d'éditeur pour tous les assemblys utilisés par l'application, placez ce paramètre dans l'élément <assemblyBinding>. Vous pouvez aussi utiliser l'outil .NET Framework Configuration (Mscorcfg.msc) pour ignorer la stratégie d'éditeur.
La valeur par défaut de l'attribut apply est yes. Lorsque l'attribut apply a la valeur no, les paramètres yes antérieurs sont substitués. Par exemple, si apply est réglé sur no au niveau de l'application, les réglages spécifiques d'assembly sont ignorés, même lorsque la valeur déclarée est yes. La valeur no est par conséquent le seul état utile, dans la mesure où elle modifie la valeur par défaut.
Redirection des versions d'assemblys
Pour rediriger une version vers une autre, utilisez l'élément <bindingRedirect>. L'attribut oldVersion permet de spécifier une version unique ou une plage de versions. Par exemple, <bindingRedirect oldVersion="1.1.0.0-1.2.0.0" newVersion="2.0.0.0"/> indique que le runtime doit utiliser la version 2.0.0.0 au lieu des versions d'assembly comprises entre 1.1.0.0 et 1.2.0.0.
Exemple
L'exemple suivant illustre la redirection d'une version de myAssembly vers une autre, ainsi que la désactivation de la stratégie d'éditeur pour mySecondAssembly.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<!-- Assembly versions can be redirected in application,
publisher policy, or machine configuration files. -->
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="mySecondAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<!-- Publisher policy can be set only in the application
configuration file. -->
<publisherPolicy apply="no" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Redirection des liaisons d'assembly .NET Framework
Vous pouvez utiliser l'attribut appliesTo sur l'élément <assemblyBinding> d'un fichier de configuration d'application pour rediriger les références de liaison d'assembly vers une version spécifique du .NET Framework. Cet attribut facultatif utilise un numéro de version du .NET Framework pour indiquer la version à laquelle il s'applique. Si aucun attribut appliesTo n'est spécifié, l'élément <assemblyBinding> s'applique à toutes les versions du .NET Framework.
L'attribut appliesTo a été introduit dans le .NET Framework version 1.1 ; il est ignoré par le .NET Framework version 1.0. Cela signifie que tous les éléments <assemblyBinding> sont appliqués lorsque vous utilisez le .NET Framework version 1.0, même si un attribut appliesTo est spécifié.
Par exemple, pour rediriger les liaisons d'assembly pour le Regcode d'assembly du .NET Framework version 1.0, vous pouvez inclure le code XML suivant dans votre fichier de configuration d'application.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"
appliesTo="v1.0.3705">
<dependentAssembly>
<!-- assembly information goes here -->
</dependentAssembly>
</assemblyBinding>
</runtime>
Les éléments <assemblyBinding> respectent l'ordre. Ainsi, vous devez d'abord entrer les informations de redirection des liaisons des assemblys du .NET Framework version 1.0, suivies de celles des assemblys du .NET Framework version 1.1. Enfin, vous devez entrer les informations de redirection des liaisons d'assembly pour toutes les redirections d'assembly du .NET Framework qui n'utilisent pas l'attribut appliesTo et s'appliquent donc à toutes les versions du .NET Framework. En cas de conflit de redirection, la première instruction de redirection correspondante du fichier de configuration est utilisée.
Par exemple, pour rediriger une référence à un assembly du .NET Framework version 1.0 et une autre à un assembly du .NET Framework version 1.1, utilisez le modèle indiqué dans le pseudo-code suivant.
<assemblyBinding xmlns="..." appliesTo="v1.0.3705">
<!—.NET Framework version 1.0 redirects here -->
</assemblyBinding>
<assemblyBinding xmlns="..." appliesTo="v1.1.5000">
<!—.NET Framework version 1.1 redirects here -->
</assemblyBinding>
<assemblyBinding xmlns="...">
<!-- redirects meant for all versions of the runtime -->
</assemblyBinding>
Voir aussi
Tâches
Comment : créer une stratégie d'éditeur
Concepts
Méthode de localisation des assemblys par le runtime
Référence
Schéma des paramètres d'exécution
Autres ressources
Assemblys dans le Common Language Runtime