Condiciones de MSBuild

  • Artículo

MSBuild admite un conjunto específico de condiciones que se pueden aplicar siempre que se Conditionpermita un atributo; vea elementos admitidos. En la siguiente tabla se explican esas condiciones.

Condición Descripción
'stringA' == 'stringB' Se evalúa como true si stringA es igual a stringB.

Por ejemplo:

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

Las comillas simples no son necesarias para cadenas alfanuméricas simples ni valores booleanos. Sin embargo, las comillas simples son necesarias para los valores vacíos. Esta comprobación no distingue mayúsculas de minúsculas.
'stringA' != 'stringB' Se evalúa como true si stringA no es igual a stringB.

Por ejemplo:

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

Las comillas simples no son necesarias para cadenas alfanuméricas simples ni valores booleanos. Sin embargo, las comillas simples son necesarias para los valores vacíos. Esta comprobación no distingue mayúsculas de minúsculas.
<, , ><= , >= Evalúa los valores numéricos de los operandos. Devuelve true si la evaluación relacional es verdadera. Los operandos se deben evaluar como un número decimal o hexadecimal, o bien una versión con puntos de cuatro partes. Los números hexadecimales deben comenzar por 0x. Nota: En XML, los caracteres < y > deben ser de escape. El símbolo < se representa como &lt;. El símbolo > se representa como &gt;.
Existe ('stringA') Se evalúa como true si existe un archivo o una carpeta con el nombre stringA.

Por ejemplo:

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

Las comillas simples no son necesarias para cadenas alfanuméricas simples ni valores booleanos. Sin embargo, las comillas simples son necesarias para los valores vacíos. Esta condición no expande caracteres comodín como *.
HasTrailingSlash ('stringA') Se evalúa como true si la cadena especificada contiene al final un carácter de barra inversa (\) o barra diagonal (/).

Por ejemplo:

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

Las comillas simples no son necesarias para cadenas alfanuméricas simples ni valores booleanos. Sin embargo, las comillas simples son necesarias para los valores vacíos.
! Se evalúa como true si el operando se evalúa como false.
And Se evalúa como true si ambos operandos se evalúan como true.
Or Se evalúa como true si al menos uno de los operandos se evalúa como true.
() Mecanismo de agrupamiento que se evalúa como true si las expresiones que contiene se evalúan como true.
$if$ ( %expression% ), $else$, $endif$ Comprueba si el %expression% especificado coincide con el valor de cadena del parámetro de plantilla personalizado pasado. Si la condición $if$ se evalúa como true, sus instrucciones se ejecutan; en caso contrario, se comprueba la condición $else$. Si la condición $else$ es true, sus instrucciones se ejecutan; en caso contrario, la condición $endif$ finaliza la evaluación de expresiones.

Para obtener ejemplos de uso, vea Visual Studio project/item template parameter logic (Lógica del parámetro de plantillas de proyecto o elemento de Visual Studio).

El Condition elemento es una sola cadena, por lo que las cadenas que se usan en la expresión, incluidos los valores de propiedad alrededor de , deben incluirse entre comillas simples. Se permiten espacios entre operadores y se usan habitualmente para la legibilidad, pero no son necesarios.

Para usar los operadores Boolean And y Or , especifique operandos dentro Condition del valor de cadena del elemento, como en el ejemplo siguiente:

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

Puede encadenar los operadores booleanos. El operador And tiene mayor prioridad que Or, pero para mayor claridad, se recomienda usar paréntesis al usar varios operadores booleanos para hacer explícito el orden de evaluación. Si no lo hace, MSBuild proporciona la advertencia MSB4130.

En las condiciones se pueden usar métodos de cadena, como se muestra en el ejemplo siguiente, donde la función TrimEnd() se usa para comparar solo la parte pertinente de la cadena, con el fin de diferenciar entre las plataformas de destino .NET Framework y .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>

En los archivos del proyecto MSBuild, no hay ningún tipo booleano true. Los datos booleanos se representan en propiedades que podrían estar vacías o establecerse en cualquier valor. Por lo tanto, '$(Prop)' == 'true' significa "si Prop es true", pero '$(Prop)' != 'false' significa "si Prop es true o anular o establecer en otra cosa".

La lógica booleana solo se evalúa en el contexto de las condiciones, por lo que los valores de propiedad como <Prop2>'$(Prop1)' == 'true'</Prop> se representan como una cadena (después de la expansión de variables), no se evalúan como valores booleanos.

MSBuild implementa algunas reglas de procesamiento especiales para facilitar el trabajo con propiedades de cadena que se usan como valores booleanos. Los literales booleanos se aceptan, por lo que Condition="true" y Condition="false" funcionan según lo previsto. MSBuild también incluye reglas especiales para admitir el operador booleano de negación. Por lo tanto, si $(Prop) es "true", !$(Prop) se expande a !true y este valor compara igual a false, como cabría esperar.

Comparación de versiones

Los operadores relacionales <, >, <= y >= admiten versiones analizadas por System.Version, por lo que puede comparar entre sí versiones que tienen cuatro partes numéricas. Por ejemplo, '1.2.3.4' < '1.10.0.0' es true.

Precaución

Las comparaciones de System.Version pueden producir resultados sorprendentes cuando una o ambas versiones no especifican las cuatro partes. Por ejemplo, la versión 1.1 es anterior a la versión 1.1.0.

MSBuild proporciona funciones de propiedad para comparar versiones que tienen un conjunto diferente de reglas compatibles con el control de versiones semántico (semver).

Expansiones en condiciones

Dependiendo de la posición en el archivo del proyecto, puede usar expansiones para propiedades ($), listas de elementos (@) y metadatos de elementos (%). Las expansiones dependen de cómo MSBuild procesa los archivos de proyecto.

Propiedades

Una condición que contiene una expresión como $(SomeProperty) se evalúa y se convierte en el valor de propiedad. Si la condición está fuera de un destino, la expresión se evalúa durante la evaluación del archivo del proyecto. El valor de la propiedad depende de la posición en el archivo de proyecto después de expandir todas las importaciones. Si la condición está en un destino, se evalúa cuando se ejecuta el destino y el valor se ve afectado por los cambios que se producen durante la ejecución de la compilación.

Propiedad que no está definida en el punto del archivo de proyecto expandido donde la expresión de condición se evalúa como una cadena vacía, sin ningún error de diagnóstico ni advertencia.

Listas de elementos

Una condición que contiene una expresión @, como @(SomeItems), se expande en grupos de elementos en el nivel superior y en destinos.

Los elementos pueden depender de cualquier propiedad, y pueden depender de elementos que ya están definidos en la secuencia.

El motivo es que MSBuild procesa los archivos de proyecto en varios pasos. El pase de evaluación de elementos se produce después de la evaluación inicial de la propiedad y el pase de la expansión de importación. Por lo tanto, se permiten expresiones @ en cualquier condición que se evalúe después de que se hayan empezado a definir los elementos. Es decir, en elementos, grupos de elementos y en destinos.

Metadatos

Una condición que contiene una expresión de metadatos como %(ItemMetadata) se expande en los mismos contextos que las listas de elementos, es decir, en grupos de elementos en el nivel superior y en destinos. Sin embargo, la expansión puede tener un comportamiento diferente en un grupo de elementos en función de si el grupo de elementos está fuera de un destino o dentro de un destino. Además, de las distintas formas de expresiones de metadatos, %(ItemName.MetadataName), %(JustTheMetadataName) y @(ItemName->'%(MetadataName)'), solo se permite la transformación de elementos (la última) fuera de un destino. El valor de una expresión % en un destino se evalúa en el entorno de ejecución y depende de los cambios de estado durante la ejecución de destino. La ejecución del destino y el valor de cualquier expresión % contenida en él también depende del procesamiento por lotes del destino y, además, puede desencadenar el procesamiento por lotes; consulte Procesamiento por lotes de MSBuild.

Elementos admitidos

Los siguientes elementos admiten el atributo Condition :

  • Importar
  • ImportGroup
  • Elemento
  • ItemDefinitionGroup
  • ItemGroup
  • ItemMetadata
  • OnError
  • Output
  • Propiedad
  • PropertyGroup
  • Destino
  • Tarea
  • UsingTask
  • Cuando

Consulte también