Comment est-ce que je détecte à l’exécution que .NET version 4.5 exécute actuellement votre code?

J’ai installé l’aperçu du développeur .NET 4.5 à l’ adresse http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27541 , qui «remplace» la version .NET 4.0.

Cependant, l’ancienne façon de détecter la version du framework .NET semble renvoyer la version 4.0 (plus précisément 4.0.30319.17020 sur mon PC), au lieu de la version 4.5 (certainement pour des raisons de compatibilité descendante ou?):

using System; namespace ConsoleApplication { class Program { static void Main(ssortingng[] args) { var version = Environment.Version; Console.WriteLine(version.ToSsortingng()); Console.ReadKey(); } } } 

Comment puis-je détecter que mon code est réellement exécuté par .NET 4.5?

Vous devez faire une distinction claire entre le CLR (c.-à-d. Le runtime) et les bibliothèques de framework (ie le “framework”). Vous exécutez votre code sur ou avec le premier, votre code est compilé et utilise le dernier. Malheureusement, lorsque l’on utilise le terme ” version .NET”, on se réfère généralement à l’ensemble du package à la fois d’exécution et de framework, quelles que soient leurs versions individuelles qui, comme on l’a dit, peuvent différer.

Vous pouvez détecter les versions du framework installées . Cela ne vous dit cependant pas lequel vous utilisez réellement lors de l’exécution.

Je ne suis pas sûr de 4.5, mais avec 2.0 vs 3.0 ou 3.5 Environment.Version n’a pas aidé car il a toujours renvoyé 2.0 car toutes ces versions de framework utilisaient la CLR 2.0. Je suppose qu’avec le framework 4.5, la version CLR est toujours 4.0, ce qui expliquerait Environment.Version renvoie 4.0.x même dans ce cas.

Une technique qui peut fonctionner pour vous consiste à rechercher un type, une méthode ou une propriété dans les bibliothèques principales (mscorlib, System.Core, etc.) que vous ne connaissez que depuis une version du framework .NET.

Par exemple, la classe ReflectionContext semble être totalement nouvelle avec le framework .NET 4.5 et se trouve commodément dans mscorlib . Donc, vous pourriez faire quelque chose comme ça.

  public static bool IsNet45OrNewer() { // Class "ReflectionContext" exists from .NET 4.5 onwards. return Type.GetType("System.Reflection.ReflectionContext", false) != null; } 

Tout cela étant dit, on peut se demander pourquoi vous devez savoir quelle version de .NET vous utilisez. Essayez simplement d’accéder aux fonctionnalités dont vous avez besoin et éventuellement de revenir à quelque chose d’autre (qui était disponible dans les anciennes versions) si elles ne sont pas présentes.

Mise à jour : Notez que le terme .NET 4.5 fait référence à l’ensemble de plusieurs assemblys qui constituent les bibliothèques de classes de base (BCL) et plus (collectivement appelées “framework”), plus le runtime lui-même, à savoir le CLR. différentes versions, comme cela a été dit.

Je ne travaille pas pour Microsoft et je ne connais pas les véritables raisons du manque de fonction (ou d’API) unique pour obtenir «la version du framework .NET», mais je peux faire une supposition éclairée.

  1. Il n’est pas clair quelles informations en particulier une telle fonction / API doit fournir. Même les assemblages individuels de la BCL ne partagent pas une version commune (assemblage / fichier). Par exemple, avec .NET 3.0 et 3.5, le fichier mscorlib.dll était doté de la version 2.0.x, alors que seuls les nouveaux assemblys de WCF et WF en avaient quelque chose. Je pense même avec .NET 3.5 le System.ServiceModel.dll avait toujours la version 3.0.x. Ce que j’essaie de dire, il n’y a pas de version unifiée sur tous les assemblages du framework. Alors, que devrait appeler un appel API, par exemple, System.Environment.FrameworkVersion ? Quelle valeur aurait la version (même si elle renvoyait la version “symbolique” comme 4.5, elle aurait peu de valeur, n’est-ce pas?).

  2. Trop spécifique Certaines nouvelles fonctionnalités peuvent arriver dans les SP vers des versions existantes, et faire partie d’une nouvelle version. En effectuant la vérification des fonctionnalités, votre application peut parfaitement fonctionner sur les versions précédentes , qui ont été mises à jour, tandis qu’avec la vérification explicite des versions, elle peut se limiter à la version la plus récente. Je n’ai pas d’exemple du monde .NET pour cela, mais en général (et sous Windows lui-même, par exemple WMI), il peut et a bien eu lieu.

  3. Non désiré. Je pourrais imaginer qu’une méthode pour déterminer “la version du framework” actuellement utilisée par une application n’est même pas souhaitable pour eux. Il existe une longue et impie histoire des erreurs de vérification de version (voir le paragraphe “Ne pas vérifier la version” pour les concepts qui s’appliquent également à .NET), dans le monde natif / Win32. Par exemple, les GetVersion GetVersionEx mal utilisé les API GetVersion et GetVersionEx , en vérifiant uniquement qu’ils GetVersionEx la version qu’ils savaient être la plus récente lorsqu’ils écrivaient leur application. Ainsi, lorsque l’application était exécutée sur une nouvelle version de Windows, elle ne s’exécutait pas, même si les fonctionnalités qu’elle utilisait étaient toujours présentes. Microsoft a peut-être envisagé des problèmes de ce type et n’a même pas fourni d’API dans .NET.

Incidemment, c’est ce que Microsoft recommande dans la section remarques de la fonction GetVersion:

Identifier le système d’exploitation actuel n’est généralement pas le meilleur moyen de déterminer si une fonction de système d’exploitation particulière est présente. Cela est dû au fait que de nouvelles fonctionnalités ont été ajoutées au système d’exploitation dans une DLL redissortingbuable. Plutôt que d’utiliser GetVersionEx pour déterminer la plate-forme du système d’exploitation ou le numéro de version, testez la présence de la fonctionnalité elle-même.

Le blog Windows Team a également quelque chose à dire à ce sujet.

Je sais que tout cela concernait Windows et la programmation native, mais le concept et les dangers sont les mêmes pour les applications .NET, le framework et le CLR.

Je dirais que la vérification des fonctionnalités avec une solution de secours (gracieuse) est donc un moyen beaucoup plus fiable et robuste pour vous assurer que votre application est compatible avec les versions antérieures. Si vous voulez seulement que votre application fonctionne avec une version spécifique de .NET ou plus récente, ne faites rien de spécial et comptez sur la rétrocompatibilité de .NET lui-même.

Le .NET Framework 4.5 est une mise à niveau sur place vers 4.0. Cela signifie que si vous utilisez une version 4.0 ou 4.5 et que la version 4.5 est installée, alors vous utilisez certainement la version 4.5. Votre chèque peut aller comme suit.

Appelons à la fois les runtimes 4.0 et versions 4.0 runtime .

  1. Vérifiez si vous exécutez sur un runtime version 4.0:

    • Si votre assembly est compilé pour cibler .NET 4.0 ou
    • Environment.Version.Major == 4 && Environment.Version.Minor == 0

    alors vous exécutez sur un runtime 4.0-versioned.

  2. Vérifiez si votre runtime version 4.0 est en fait la version 4.0 ou 4.5, en vérifiant la version installée:

    • Sous la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client , vérifiez la valeur _Version_ . S’il commence par "4.0" vous exécutez sur le runtime 4.0, s’il commence par "4.5" vous êtes sur le runtime 4.5.

Pour déterminer exactement quel correctif de .NET est exécuté par votre application, vous pouvez effectuer cet appel pour rechercher la version de compilation de mscorlib:

 System.Diagnostics.FileVersionInfo.GetVersionInfo(typeof(int).Assembly.Location).ProductVersion 

Il retourne actuellement 4.6.1055.0 pour moi, ce qui correspond à .NET 4.6.1.

Vous pouvez tester si .NET Framework 4.5 ou .NET Framework 4 est installé en vérifiant la sous- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full dans le Registre pour une valeur DWORD nommée Release . L’existence de ce DWORD indique que le .NET Framework 4.5 a été installé sur cet ordinateur. La valeur de Release est un numéro de version. Pour déterminer si la version finale de .NET Framework 4.5 est installée, vérifiez que la valeur est égale ou supérieure à 378389 .

James fournit la bonne réponse pour récupérer la “version du produit” de mscorlib.dll à l’exécution:

(en using System.Diagnostics; )

 FileVersionInfo.GetVersionInfo(typeof(int).Assembly.Location).ProductVersion 

Cela fonctionne bien, mais vous pouvez obtenir un résultat plus fin en examinant System.dll à la place:

 FileVersionInfo.GetVersionInfo(typeof(Uri).Assembly.Location).ProductVersion 

Notez que la légère différence consiste à utiliser l’assembly pour typeof(Uri) au lieu de typeof(int) , puisque le premier est défini dans System.dll par opposition à mscorlib.dll pour ce dernier. Pour un simple programme de console C # ciblant .NET 4.7.1 , la différence, comme indiqué actuellement sur mon système, est la suivante :

… \ Microsoft.NET \ Framework \ v4.0.30319 \ mscorlib.dll 4.7. 2600 .0 … \ Microsoft.NET \ Framework \ v4.0.30319 \ System.dll 4.7. 2556 .0

Quant à savoir si la distinction est utile ou comment utiliser les informations plus détaillées, cela dépendra de la situation particulière.

D’après ce que j’ai compris des ressources en ligne, .NET 4.5 agira de la même manière (bien que pas complètement le même) que 3.5 pour 2.0: votre numéro de version rest le même (si vous exécutez le code 3.5, la version CLR sera 2.0), et il agira comme une mise à jour du CLR 4.0 existant.

Ainsi, vous pourrez faire évoluer la version 2.0 vers la version 3.5 et 4.0 vers la version 4.5.

Ce qui rest incertain, c’est s’il sera possible de créer (ou de travailler sur des projets existants) en 4.0 sans avoir à les mettre à niveau vers 4.5: actuellement, vous pouvez créer des projets 2.0 ou 3.5 dans Visual Studio 2010, mais ce ne sera peut-être pas la même pour 4.0 et 4.5.