Unification des assemblys .NET Framework
Dans l'exécution côte à côte, il est possible qu'une application soit composée de composants générés à l'aide de versions différentes du .NET Framework. Cela peut créer des conflits entre les dépendances des composants. Par exemple, supposons qu'un composant A est généré à l'aide du .NET Framework version 1.0 et doit utiliser la version 1.0 de l'assembly System.Data. Supposons qu'un composant B est généré à l'aide du .NET Framework version 1.1 et doit utiliser la version 1.1 de l'assembly System.Data. Si les versions de l'assembly sont incompatibles mais sont chargées simultanément, cela peut entraîner des exceptions de cast involontaires, voir des problèmes plus graves.
Détermination par une application de la version .NET Framework à utiliser
Pour résoudre ce problème, lorsqu'une application utilise des composants générés sur différentes versions du .NET Framework, la version du runtime associée à une application détermine la version des assemblys .NET Framework utilisée par l'application et tous ses composants. Dans l'exemple précédent, si l'application est associée à la version 1.1 du .NET Framework, la version 1.1 de l'assembly System.Data est ensuite chargée et partagée entre tous les composants utilisés par l'application. La référence du composant A à la version 1.0 de l'assembly System.Data est promue au moment de l'exécution à la référence version 1.1.
Vous pouvez substituer ce comportement en ajoutant les éléments <bindingRedirect> aux fichiers Machine.config ou Web.config. Une application peut ainsi utiliser la version d'un assembly mise à jour conçue pour remplacer un assembly existant pour certains types d'applications. Par exemple, si une version mise à jour de System.Web.Service.dll est publiée à l'avenir et prend en charge SOAP version 1.2, vous voudrez peut-être que votre application utilise cette version, au lieu de la version installée avec le runtime d'origine.
Ce comportement peut être également substitué dans le fichier de configuration d'hôte ASP.NET (Aspnet.config). ASP.NET utilise ce fichier pour garantir que la version de System.Web.dll et System.Web.RegularExpressions.dll correspond toujours à la version du runtime associée à une application, quelles que soient les substitutions dans le fichier Web.config.
Parfois vous pouvez être amené à utiliser un composant généré à l'aide d'une version ultérieure de ASP.NET dans une application générée avec une version antérieure. N'oubliez pas que la version ISAPI ASPNET associée à une application détermine toujours la version du runtime utilisée pour une application. Si l'application est configurée pour utiliser la version antérieure du runtime, le composant sera redirigé automatiquement au moment de l'exécution afin d'utiliser également cette version. Lors de l'utilisation d'un composant généré avec une version ultérieure du .NET Framework dans une application générée sur une version antérieure, prenez en compte les points suivants :
- Veillez à ce que le composant n'utilise pas de fonctionnalités ou ne dépende pas de comportements spécifiques à la version ultérieure du .NET Framework. Ces fonctionnalités peuvent ne pas être disponibles dans la version antérieure du runtime.
- ASP.NET utilise des scriptmaps dans IIS pour lier une application à une version du runtime. Les éléments de configuration <supportedRuntime> et <requiredRuntime> ne s'appliquent pas aux applications ASP.NET.
Si la version du runtime utilisée pour générer le composant est installée sur l'ordinateur, vous pouvez également reconfigurer l'application pour qu'elle utilise la version ultérieure du runtime. Comme les versions ultérieures du .NET Framework sont conçues pour être compatibles en amont, l'application doit fonctionner sans modifications. Pour des informations sur la configuration d'une application ASP.NET pour qu'elle utilise une version spécifique du runtime, consultez Configuration d'une application ASP.NET pour une version ASP.NET.
Voir aussi
Prise en charge de l'exécution côte à côte dans ASP.NET | <bindingRedirect>