Partage via

Conditions MSBuild

  • Article

MSBuild prend en charge un ensemble spécifique de conditions qui peuvent être appliquées partout où un attribut Condition est autorisé ; consultez éléments pris en charge. Le tableau suivant décrit ces conditions.

Condition Description
'stringA' == 'stringB' Prend la valeur true si stringA est égal à stringB.

Par exemple:

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

Les guillemets simples ne sont pas obligatoires pour les chaînes alphanumériques simples ou les valeurs booléennes. Toutefois, les guillemets simples sont requis pour les valeurs vides. Cette vérification ne respecte pas la casse.
'stringA' != 'stringB' Prend la valeur true si stringA n’est pas égal à stringB.

Par exemple:

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

Les guillemets simples ne sont pas obligatoires pour les chaînes alphanumériques simples ou les valeurs booléennes. Toutefois, les guillemets simples sont requis 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 est vraie. Les opérandes doivent évaluer un nombre décimal ou hexadécimal ou une version en pointillé à quatre parties. Les nombres hexadécimaux doivent commencer par 0x. Remarque : en XML, les caractères < et > doivent être placés dans l’échappement. Le symbole < est représenté en tant que &lt;. Le symbole > est représenté en tant que &gt;.
Exists('stringA') Prend la valeur true si un fichier ou un dossier portant le nom stringA existe.

Par exemple:

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

Les guillemets simples ne sont pas obligatoires pour les chaînes alphanumériques simples ou les valeurs booléennes. Toutefois, les guillemets simples sont requis pour les valeurs vides. Cette condition ne développe pas les caractères génériques tels que *.
HasTrailingSlash('stringA') Prend la valeur true si la chaîne spécifiée contient une barre oblique vers l’arrière (\) ou un caractère de barre oblique (/).

Par exemple:

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

Les guillemets simples ne sont pas obligatoires pour les chaînes alphanumériques simples ou les valeurs booléennes. Toutefois, les guillemets simples sont requis pour les valeurs vides.
! Prend la valeur true si l’opérande prend la valeur false.
And Prend la valeur true si les deux opérandes sont évalués à true.
Or Prend la valeur true si au moins l’un des opérandes prend la valeur true.
() Mécanisme de regroupement qui prend la valeur true si les expressions contenues à l’intérieur sont évaluées à true.
$if$ ( %expression% ), $else$, $endif$ Vérifie si le %expression% spécifié correspond à la valeur de chaîne du paramètre de modèle personnalisé passé. Si la condition $if$ prend la valeur true, ses instructions sont exécutées ; sinon, la condition $else$ est vérifiée. Si la condition $else$ est true, ses instructions sont exécutées ; sinon, la condition $endif$ met fin à l’évaluation de l’expression.

Pour obtenir des exemples d’utilisation, consultez logique de paramètre de modèle de projet/élément Visual Studio.

L’élément Condition est une chaîne unique, et ainsi 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 And et Or, spécifiez des opérandes à l’intérieur de la valeur de chaîne de l’élément Condition, 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é supérieure à 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 ce n’est pas le cas, MSBuild donne des MSB4130 d’avertissement.

Vous pouvez utiliser des méthodes de chaîne dans des conditions, comme indiqué dans l’exemple suivant, dans lequel la fonction TrimEnd() est utilisée pour comparer uniquement la partie pertinente de la chaîne, pour différencier les frameworks 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 projet MSBuild, il n’existe aucun type booléen vrai. Les données booléennes sont représentées dans les propriétés qui peuvent être vides ou définies sur n’importe quelle valeur. Par conséquent, '$(Prop)' == 'true' signifie « if Prop is true», mais '$(Prop)' != 'false' signifie « if Prop is true or unset or set to something else ».

La logique booléenne n’est évaluée que dans le contexte des conditions, de sorte que les paramètres de propriété tels que <Prop2>'$(Prop1)' == 'true'</Prop> sont représentés sous forme de chaîne (après l’expansion de variable), non évalués 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. Par conséquent, si $(Prop) est « true », !$(Prop) s’étend sur !true et cette valeur est comparée à false, comme prévu.

Comparaison des versions

Les opérateurs relationnels <, >, <=et >= prennent en charge les versions comme analysées par System.Version, afin de pouvoir comparer les versions qui ont quatre parties numériques les unes aux autres. Par exemple, '1.2.3.4' < '1.10.0.0' est true.

Prudence

System.Version comparaisons 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 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 en conditions

Selon la position du 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 expansions dépendent de comment MSBuild traite les fichiers projet.

Propriétés

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 pendant l’évaluation du fichier projet. La valeur de la propriété dépend de la position dans le fichier projet après avoir développé 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.

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 des éléments déjà définis dans la séquence.

C’est pourquoi MSBuild traite les fichiers projet dans plusieurs passes. La passe d’évaluation de l’élément se produit après l’évaluation initiale des propriétés et la passe d’extension d’importation. Par conséquent, les @-expressions sont autorisées dans n’importe quelle 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 est en dehors d’une cible ou à l’intérieur d’une cible. En outre, des 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’un %-expression dans une cible est évaluée au moment de l’exécution et dépend des modifications d’état au cours de l’exécution de la cible. L’exécution de la cible et la valeur de n’importe quelle %-expressions contenues dans celle-ci dépend également du traitement par lots de la cible et peut également déclencher le traitement par lots ; consultez de traitement par lots MSBuild.

Éléments pris en charge

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

  • Importation
  • ImportGroup
  • Article
  • ItemDefinitionGroup
  • ItemGroup
  • ItemMetadata
  • OnError
  • Sortie
  • Propriété
  • PropertyGroup
  • Cible
  • Tâche
  • UsingTask
  • Quand

Voir aussi