2010-03-07 3 views
3

Je construis une bibliothèque de classe C# et j'utilise la version bêta 2 de Visual Web Developer/Visual C# 2010. J'essaie d'enregistrer des informations sur la version de .NET dans laquelle la bibliothèque a été construite. Dans le passé, j'ai pu utiliser ceci:Qu'est-il arrivé à la définition de version .NET avec v4.0?

// What version of .net was it built under? 
#if NET_1_0 
     public const string NETFrameworkVersion = ".NET 1.0"; 
#elif NET_1_1 
     public const string NETFrameworkVersion = ".NET 1.1"; 
#elif NET_2_0 
     public const string NETFrameworkVersion = ".NET 2.0"; 
#elif NET_3_5 
     public const string NETFrameworkVersion = ".NET 3.5"; 
#else 
     public const string NETFrameworkVersion = ".NET version unknown"; 
#endif 

Je pensais que je pouvais ajouter:

#elif NET_4_0 
     public const string NETFrameworkVersion = ".NET 4.0"; 

Maintenant, dans Projet-> Propriétés, mon cadre cible est » .NET Framework 4 ". Si je vérifie:

Assembly.GetExecutingAssembly().ImageRuntimeVersion 

Je peux voir ma version d'exécution est v4.0.21006 (donc je sais que j'ai .NET 4.0 installé sur mon CPU). Je m'attends naturellement à voir que ma variable NETFrameworkVersion contient ".NET 4.0". Ce ne est pas. Il contient ".NET version unknown". Donc, ma question est la suivante: pourquoi NET_4_0 n'est-il pas défini? La convention de dénomination a-t-elle changé? Existe-t-il une autre façon simple de déterminer la version de la construction du framework .NET dans les versions> 3.5?

+3

D'où proviennent les constantes NET_2_0, NET_3_5 etc.? Je peux trouver beaucoup de références à eux dans les documents Mono, mais rien de officiel sur microsoft.com. –

+0

Tom, avez-vous vérifié votre fichier csproj pour voir s'il y avait d'autres inclusions ou cibles autres que les standards Microsoft? Cela peut être une fonctionnalité de construction personnalisée incluse dans ce projet. –

Répondre

3

Les manafestes de numéro de version NET_x_y dont vous parlez n'ont jamais fait partie d'une spécification officielle, et il semblerait que Microsoft les ait abandonnées.

+0

Hmmm, cela pourrait être le cas. Je pourrais trouver très peu de références à eux quand j'étais Google. Peut-être qu'un développeur précédent sur mon projet est tombé sur ceci et cela a fonctionné jusqu'à maintenant. –

+0

En outre, l'indicateur utilisé par Visual Studio via un argument de ligne de commande pour le compilateur; il n'a pas été défini par le compilateur lui-même. C'est dangereux car si vous changez la méthodologie de construction pour NAnt ou similaire, vous devrez émuler le comportement de Visual Studio. –

+0

On dirait que nous devons nous en sortir. Merci! –

0

Qu'est-ce qui ne va pas avec Environment.Version?

+0

Il cherche très probablement à utiliser une fonctionnalité spécifique à l'environnement au moment de la compilation ... c'est-à-dire à appeler une méthode qui n'existe pas dans certains Frameworks. Vous devriez utiliser la réflexion pour faire cela à l'exécution. –

+0

David, mon projet les utilisait fréquemment à cette fin. –

+0

En outre: "Malheureusement, cela vous indique la version .NET CLR (bibliothèque d'exécution), pas la version de .NET Framework.Ces deux numéros de version ne sont pas toujours les mêmes, en particulier, le .NET Framework 3.0 et 3.5 utilisent tous les deux le .NET CLR 2.0. " Via: http://stackoverflow.com/questions/37468/how-to-determine-the-installed-asp-net-version-of-host-from-a-web-page/37530#37530 –

0
Assembly.ImageRuntimeVersion 

contient la version d'exécution d'un assemblage a été compilé, donc il n'y a pas besoin de cette bidouille horrible que vous faites avec les directives de préprocesseur du tout.

+0

Foxfire, la documentation de mon projet contient un lien vers http://msdn.microsoft.com/en-us/library/system.reflection.assembly.imageruntimeversion. qui contient la note: Par défaut, ImageRuntimeVersion est défini sur la version de la CLR utilisée pour générer l'assembly. Cependant, il peut avoir été défini sur une autre valeur au moment de la compilation. Je pense que c'est TOUJOURS la raison pour laquelle nous avons essayé d'obtenir la version d'une autre manière, bien que je puisse me tromper. L'autre raison est la compilation conditionnelle de fonctions qui utilisent des méthodes qui n'existent que dans certaines versions. –

+0

A noter également: la propriété Assembly.ImageRuntimeVersion n'était apparemment pas disponible sous .NET Framework 1.0. Pas que je pense que quiconque impliqué dans le projet utiliserait encore 1.0 ... ou que nous le soutenions toujours officiellement ... –