65 votes

Détecter la cible framework version au moment de la compilation

J'ai un code qui rend l'utilisation de Méthodes d'Extension, mais compile sous .NET 2.0 à l'aide du compilateur dans VS2008. Pour faciliter cela, j'ai dû déclarer ExtensionAttribute:

/// <summary>
/// ExtensionAttribute is required to define extension methods under .NET 2.0
/// </summary>
public sealed class ExtensionAttribute : Attribute
{
}

Cependant, maintenant, j'aimerais la bibliothèque dans laquelle cette catégorie est contenue aussi être compilable sous .NET 3.0, 3.5 et 4.0 - sans le " ExtensionAttribute est défini dans plusieurs lieux d'avertissement.

Il y a tout moment de la compilation, de la directive que je peux utiliser pour inclure uniquement les ExtensionAttribute quand le cadre de la version visée est .NET 2?

66voto

James Manning Points 7989

Le rattachement de la question avec "créer N différentes configurations' est certainement une option, mais quand j'ai eu besoin pour cela j'ai juste ajouté conditionnelle DefineConstants éléments, donc, à mon Debug|x86 (par exemple) après l'DefineConstants pour DEBUG;TRACE, j'ai ajouté ces 2, de la vérification de la valeur du FONDS au profit des victimes a été défini dans la première PropertyGroup du fichier csproj.

<DefineConstants Condition=" '$(TargetFrameworkVersion)' == 'v4.0' ">RUNNING_ON_4</DefineConstants>
<DefineConstants Condition=" '$(TargetFrameworkVersion)' != 'v4.0' ">NOT_RUNNING_ON_4</DefineConstants>

Vous n'avez pas besoin de les deux, évidemment, mais il est juste là pour donner des exemples de eq et ne comportement - #else et #elif travail bien aussi :)

class Program
{
    static void Main(string[] args)
    {
#if RUNNING_ON_4
        Console.WriteLine("RUNNING_ON_4 was set");
#endif
#if NOT_RUNNING_ON_4
        Console.WriteLine("NOT_RUNNING_ON_4 was set");
#endif
    }
}

J'ai pu ensuite basculer entre le ciblage 3.5 et 4.0 et qu'il serait, faire la bonne chose.

30voto

Maslow Points 7268

Les groupes de propriétés sont remplacer uniquement donc, ce serait assommer vos paramètres pour DEBUG, TRACE, ou les autres. - Voir MSBuild D'Évaluation D'Une Propriété

Aussi, si l' DefineConstants propriété est définie à partir de la ligne de commande tout ce que vous faites à l'intérieur du fichier de projet n'est pas pertinent en tant que paramètre est global en lecture seule. Cela signifie que vos modifications pour que la valeur échoue silencieusement.

Exemple le maintien des constantes définies:

    <CustomConstants Condition=" '$(TargetFrameworkVersion)' == 'v2.0' ">V2</CustomConstants>
    <CustomConstants Condition=" '$(TargetFrameworkVersion)' == 'v4.0' ">V4</CustomConstants>
    <DefineConstants Condition=" '$(DefineConstants)' != '' And '$(CustomConstants)' != '' ">$(DefineConstants);</DefineConstants>
    <DefineConstants>$(DefineConstants)$(CustomConstants)</DefineConstants>

Cette section DOIT être après d'autres constantes car ceux-ci sont peu susceptibles d'être mis en place dans une manière additive

J'ai défini ces 2 parce que c'est principalement ce que je suis intéressé par mon projet, ymmv.

Voir Aussi: Commune MsBuild Propriétés Du Projet

Prograide.com

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.

Powered by:

X