Une de nos applications web ASP.NET MVC 5 possède les paramètres web.config suivants :
<system.web>
<compilation debug="true" targetFramework="4.6" />
<httpRuntime targetFramework="4.5" />
<!--... many other things -->
</system.web>La raison pour laquelle il y a deux paramètres targetFramework n'est pas claire, et il semble que ce soit une erreur de compiler en ciblant 4.6 puis d'essayer de s'exécuter sous 4.5...
Il est évident que je rate quelque chose, mais quoi ?
La raison de targetFramework existence dans web.config est d'éviter les problèmes de compatibilité entre les changements de rupture pour chaque version de .NET Framework. La différence entre targetFramework sur compilation y httpRuntime appartient à chaque environnement de développement et de déploiement.
Selon Blog MSDN :
<compilation targetFramework="4.6" />Sélectionne la version des assemblages de référence de .NET Framework qui sont utilisées lors de la compilation. (Remarque : Visual Studio exige que cet élément soit présent dans Web.config, même si nous l'insérons automatiquement).
Cet élément détermine la version de l'assemblage utilisée lors de la compilation pour créer les dépendances et les assemblages connexes du projet actuel.
<httpRuntime targetFramework="4.5" /> signifie que le projet actuel est conçu pour utiliser les assemblages du runtime .NET 4.5 sans recompiler les assemblages du projet existant dans la machine de déploiement avant de le charger en mémoire.
Par conséquent, nous pouvons conclure que le numéro de version défini sur targetFramework sur httpRuntime élément conçu pour maintenir la compatibilité entre le projet compilé et les assemblages disponibles lors de l'utilisation du runtime, en fonction de la version des fichiers runtime utilisée sur la machine cible.
Ainsi, dans votre cas, il ne s'agit pas d'un comportement erroné, le(s) créateur(s) du projet souhaite(nt) simplement maintenir la compatibilité d'exécution à la plus basse version d'exécution disponible dans la machine cible avec des caractéristiques similaires (c'est-à-dire la version 4.5), même si le projet a été compilé avec une version plus récente des assemblages .NET. La différence entre les versions 4.5 et 4.6 est relativement faible, ce qui fait que le maintien de la version d'exécution à 4.5 reste acceptable dans ce contexte.
Références connexes :
C'est peut-être moi, mais je ne comprends toujours pas comment quelque chose "...conçu pour utiliser .NET 4.5..." alors que nous avons utilisé 4.6 lorsque nous avons sélectionné "...une version des assemblages de référence de .NET Framework est utilisée lors de la compilation...".
.NET 4.6 est une mise à jour du sous-ensemble de .NET 4.5, donc également basée sur les références d'assemblage de .NET 4.5 avec quelques différences mineures (notez que .NET a un support de rétrocompatibilité depuis la version 2.0). En fait, le projet sera compilé en utilisant les références d'assemblage de la version 4.6, mais pourra utiliser les références d'exécution de la version 4.5 sur la machine cible lorsque les versions supérieures ne sont pas disponibles.
Vous faites référence à la "rétrocompatibilité". Or, par définition, cela signifie qu'une chose qui s'attend à une version inférieure fonctionnera sans problème dans le contexte d'une version supérieure. (parce que la version supérieure est rétrocompatible" et non l'inverse.
Comme je l'ai compris <compilation debug="true" targetFramework="4.6" /> est supprimée par <httpRuntime targetFramework="4.5" /> depuis httpRuntime se traduit par ce qui suit
<compilation targetFramework="4.5" />
<machineKey compatibilityMode="Framework45" />
<pages controlRenderingCompatibilityVersion="4.5" />Le réglage ci-dessus est donc probablement dû à un malentendu ou à un bug s'il est effectué par VS directement, ce que je ne crois pas.
Pour comprendre comment ce paramètre et toutes les autres choses liées signifie ce blog intitulé Tout sur <httpRuntime targetFramework> écrit par un employé de Microsoft pourrait vous aider. Mais l'essentiel est ;
La structure .NET (y compris ASP.NET) s'efforce de maintenir une compatibilité proche de 100 % lorsqu'une structure existante est mise à jour. lorsqu'un framework existant est mis à jour sur une machine. Nous essayons d'assurer autant que possible que si une application a été développée et déployée avec le .NET Framework 4, elle continuera de fonctionner sur 4.5. Cela signifie normalement qu'il faut conserver les comportements excentriques, bogués ou indésirables dans le produit entre les versions. indésirables dans le produit entre les versions, car les corriger pourrait affecter négativement les applications qui s'appuyaient sur ces comportements.
Dans le billet de blog, il est suggéré que les paramètres explicitement définis dans le web.config ne seront pas remplacés par ce qui est impliqué par le paramètre httpRuntime : "Même si <httpRuntime targetFramework="4.5" /> impliquerait normalement <pages controlRenderingCompatibilityVersion="4.5" />, le runtime remarquera que vous avez déjà explicitement défini controlRenderingCompatibilityVersion et respectera votre paramètre."
Pour information, si la compilation est définie alors que httpRuntime n'est pas défini, les paramètres machinekey et pages n'auront pas la valeur 4.5 par défaut, il faudra les définir manuellement. Ceci est très important lorsque l'on essaie de partager des cookies entre un site Web existant et un site Web .net core.
Quelle est l'interprétation si le targetFramework est absent à la fois pour Compilation et HttpRuntime ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
5 votes
Article de blog connexe blogs.msdn.microsoft.com/webdev/2012/11/19/