Conditions MSBuild

  • Article

MSBuild prend en charge un ensemble spécifique de conditions pouvant être appliquées chaque fois qu’un attribut Condition est autorisé. Pour en savoir plus, consultez Éléments pris en charge. Le tableau suivant décrit ces conditions.

Condition Description
'stringA' == 'stringB' A la valeur true si stringA équivaut à stringB.

Par exemple :

Condition="'$(Configuration)'=='DEBUG'"

Les guillemets simples ne sont pas requis pour les chaînes alphanumériques simples ou les valeurs booléennes. mais ils le sont pour les valeurs vides. Cette vérification ne respecte pas la casse.
'stringA' != 'stringB' Évalue à true si stringA n’est pas égale à stringB.

Par exemple :

Condition="'$(Configuration)'!='DEBUG'"

Les guillemets simples ne sont pas requis pour les chaînes alphanumériques simples ou les valeurs booléennes. mais ils le sont pour les valeurs vides. Cette vérification ne respecte pas la casse.
<, , ><=, >= Évalue les valeurs numériques des opérandes. Retourne true si l’évaluation relationnelle a la valeur true. Les opérandes doivent être évalués à un nombre décimal ou hexadécimal ou à une version en pointillés en quatre parties. Les nombres hexadécimaux doivent commencer par 0x. Remarque : au format XML, les caractères < et > doivent être insérés dans une séquence d’échappement. Le symbole < est représenté sous la forme &lt;. Le symbole > est représenté sous la forme &gt;.
Exists(« stringA ») A la valeur true si un fichier ou un dossier du nom stringA existe.

Par exemple :

Condition="!Exists('$(Folder)')"

Les guillemets simples ne sont pas requis pour les chaînes alphanumériques simples ou les valeurs booléennes. mais ils le sont pour les valeurs vides. Cette condition ne développe pas les caractères génériques tels que *.
HasTrailingSlash (« stringA ») A la valeur true si la chaîne spécifiée contient une barre oblique inverse finale (\) ou une barre oblique (/).

Par exemple :

Condition="!HasTrailingSlash('$(OutputPath)')"

Les guillemets simples ne sont pas requis pour les chaînes alphanumériques simples ou les valeurs booléennes. mais ils le sont pour les valeurs vides.
! A la valeur true si l’opérande a la valeur false.
And A la valeur true si les deux opérandes ont la valeur true.
Or A la valeur true si l’un des opérandes au moins a la valeur true.
() Mécanisme de regroupement qui prend la valeur true si les expressions qu’il contient ont la valeur true.
$if$ ( %expression% ), $else$, $endif$ Vérifie si la condition %expression% spécifiée correspond à la valeur de chaîne du paramètre de modèle personnalisé transmis. Si la condition $if$ prend la valeur true, ses instructions sont exécutées ; dans le cas contraire, la condition $else$ est vérifiée. Si la condition $else$ a la valeur true, ses instructions sont exécutées. Dans le cas contraire, la condition $endif$ met fin à l’évaluation de l’expression.

Pour obtenir des exemples d’utilisation, consultez Logique des paramètres de modèles de projet/d’élément Visual Studio.

L’élément Condition est une seule chaîne, et donc toutes les chaînes utilisées dans l’expression, y compris autour des valeurs de propriété, doivent être placées entre guillemets simples. Les espaces entre les opérateurs sont autorisés et couramment utilisés pour la lisibilité, mais ils ne sont pas obligatoires.

Pour utiliser les opérateurs booléens et Or les And opérateurs, spécifiez des opérandes dans la valeur de chaîne de l’élémentCondition, comme dans l’exemple suivant :

Condition="'$(Configuration)' == 'Debug' And '$(MSBuildProjectExtension)' == '.csproj'"

Vous pouvez chaîner les opérateurs booléens. L’opérateur And a une priorité plus élevée que Or, mais pour plus de clarté, nous vous recommandons d’utiliser des parenthèses lorsque vous utilisez plusieurs opérateurs booléens pour rendre l’ordre d’évaluation explicite. Si vous ne le faites pas, MSBuild émet un avertissement MSB4130.

Vous pouvez utiliser des méthodes de chaîne dans des conditions, comme illustré dans l’exemple suivant, dans lesquelles la fonction TrimEnd() est utilisée pour comparer uniquement la partie pertinente de la chaîne, afin de différencier les infrastructures cibles .NET Framework et .NET Core.

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFrameworks>net45;net48;netstandard2.1;netcoreapp2.1;netcoreapp3.1</TargetFrameworks>
    </PropertyGroup>

    <PropertyGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net'">
        <!-- Properties for .NET Framework -->
    </PropertyGroup>

</Project>

Dans les fichiers de projet MSBuild, il n’existe pas de véritable type booléen. Les données booléennes sont représentées dans des propriétés qui peuvent être vides ou définies sur n’importe quelle valeur. Par conséquent, '$(Prop)' == 'true' signifie « si Prop a la valeur true », mais '$(Prop)' != 'false' signifie « si Prop a la valeur true ou est non défini ou défini sur quelque chose d’autre ».

La logique booléenne étant évaluée uniquement dans le contexte des conditions, les paramètres de propriété tels que <Prop2>'$(Prop1)' == 'true'</Prop> sont représentés sous la forme d’une chaîne (après l’expansion de la variable) et non en tant que valeurs booléennes.

MSBuild implémente quelques règles de traitement spéciales pour faciliter l’utilisation des propriétés de chaîne utilisées comme valeurs booléennes. Les littéraux booléens sont acceptés, donc Condition="true" et Condition="false" fonctionnent comme prévu. MSBuild inclut également des règles spéciales pour prendre en charge l’opérateur de négation booléenne. Ainsi, si $(Prop) a la valeur « true », !$(Prop) développe la valeur !true et cette valeur est égale à false, comme prévu.

Comparaison des versions

Les opérateurs de relation <, >, <= et >= prennent en charge les versions telles qu’analysées par System.Version, afin que vous puissiez comparer les versions comportant quatre parties numériques. Par exemple, '1.2.3.4' < '1.10.0.0' est true.

Attention

Les comparaisons System.Version peuvent produire des résultats surprenants quand une ou les deux versions ne spécifient pas les quatre parties. Par exemple, la version 1.1 est antérieure à la version 1.1.0.

MSBuild fournit des fonctions de propriété pour comparer les versions qui ont un ensemble différent de règles compatibles avec le contrôle de version sémantique (semver).

Expansions dans les conditions

Selon la position dans le fichier projet, vous pouvez utiliser des extensions pour les propriétés ($), les listes d’éléments (@) et les métadonnées d’élément (%). Les extensions dépendent de la façon dont MSBuild traite les fichiers projet.

Propriétés

Une condition qui contient une expression telle que $(SomeProperty) est évaluée et convertie en valeur de propriété. Si la condition est en dehors d’une cible, l’expression est évaluée lors de l’évaluation du fichier projet. La valeur de la propriété dépend de la position dans le fichier projet après le développement de toutes les importations. Si la condition se trouve dans une cible, elle est évaluée lorsque la cible s’exécute, et la valeur est affectée par les modifications qui se produisent pendant l’exécution de la build.

Une propriété qui n’est pas définie au point dans le fichier projet développé où l’expression de condition se produit est évaluée à une chaîne vide, sans erreur de diagnostic ni avertissement.

Listes d’éléments

Une condition qui contient une @-expression telle que @(SomeItems) est développée dans les groupes d’éléments au niveau supérieur et dans les cibles.

Les éléments peuvent dépendre de n’importe quelle propriété et peuvent dépendre d’éléments déjà définis dans l’ordre.

La raison en est que MSBuild traite les fichiers projet en plusieurs passes. La passe d’évaluation de l’élément se produit après l’évaluation initiale de la propriété et la passe d’extension d’importation. Par conséquent, les @-expressions sont autorisées dans toute condition évaluée après que les éléments ont commencé à être définis. Autrement dit, dans les éléments, les groupes d’éléments et dans les cibles.

Métadonnées

Une condition qui contient une expression de métadonnées telle que %(ItemMetadata) est développée dans les mêmes contextes que les listes d’éléments, autrement dit, dans les groupes d’éléments au niveau supérieur et dans les cibles. Toutefois, l’expansion peut avoir un comportement différent dans un groupe d’éléments selon que le groupe d’éléments se trouve en dehors d’une cible ou à l’intérieur d’une cible. En outre, parmi les différentes formes d’expressions de métadonnées, %(ItemName.MetadataName), %(JustTheMetadataName)et @(ItemName->'%(MetadataName)'), seule la transformation d’élément (la dernière) est autorisée en dehors d’une cible. La valeur d’une %-expression dans une cible est évaluée au moment de l’exécution et dépend de tout changement d’état au cours de l’exécution de la cible. L’exécution de la cible et la valeur de toutes les %-expressions contenues dans celle-ci dépendent également du traitement par lot de la cible et peuvent également déclencher le traitement par lot ; consultez Traitement par lots MSBuild.

Éléments pris en charge

Les éléments suivants prennent en charge l’attribut Condition :

  • Importer
  • ImportGroup
  • Article
  • ItemDefinitionGroup
  • ItemGroup
  • ItemMetadata
  • OnError
  • Sortie
  • Propriété
  • PropertyGroup
  • Cible
  • Tâche
  • UsingTask
  • Lorsque le répertoire

Voir aussi