Condiciones de MSBuild
MSBuild admite un conjunto específico de condiciones que se pueden aplicar siempre que se permita un atributo Condition; vea Elementos admitidos. En la tabla siguiente 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 true. Los operandos deben evaluarse como un número decimal o hexadecimal o una versión de puntos de cuatro partes. Los números hexadecimales deben comenzar por 0x.
Nota: En XML, los caracteres < y > deben tener escape. El símbolo < se representa como <. El símbolo > se representa como >. |
Exists("stringA') |
Se evalúa como true si existe un archivo o 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 una barra diagonal final (\) o un carácter de 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 agrupación que se evalúa como true si las expresiones contenidas en 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 personalizada pasado. Si la condición $if$ se evalúa como true, se ejecutan sus instrucciones; De lo contrario, se comprueba la condición $else$. Si la condición $else$ es true, se ejecutan sus instrucciones; de lo contrario, la condición $endif$ finaliza la evaluación de expresiones.Para obtener ejemplos de uso, consulte lógica de parámetros de plantilla de proyecto o elemento de Visual Studio. |
El elemento Condition es una sola cadena, por lo que las cadenas que se usan en la expresión, incluidos los valores de propiedad, 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 de And y Or booleanos, especifique operandos dentro del valor de cadena del elemento Condition, 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 MSB4130 de advertencia.
Puede usar métodos de cadena en condiciones, como se muestra en el ejemplo siguiente, en el que la función trimEnd() de se usa para comparar solo la parte pertinente de la cadena, para diferenciar entre las plataformas de destino de .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 de proyecto de 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 no se establece 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. Se aceptan literales booleanos, por lo que Condition="true" y Condition="false" funcionan según lo previsto. MSBuild también incluye reglas especiales para admitir el operador de negación booleano. Por lo tanto, si $(Prop) es "true", !$(Prop) se expande a !true y este valor compara igual a false, como cabría esperar.
Los operadores relacionales <, >, <=y >= admiten versiones como analizadas por System.Version, por lo que puede comparar versiones con cuatro partes numéricas entre sí. Por ejemplo, '1.2.3.4' < '1.10.0.0' es true.
Precaución
System.Version comparaciones 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).
Según la posición del archivo de 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.
Una condición que contiene una expresión como $(SomeProperty) se evalúa y se convierte en el valor de la 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 del archivo del 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.
Una condición que contiene una @-expression, 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 los elementos que ya están definidos en secuencia.
La razón 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 paso de expansión de importación. Por lo tanto, se permiten @-expressions 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.
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 los grupos de elementos en el nivel superior y en los 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 un %-expression en un destino se evalúa en tiempo de ejecución y depende de los cambios de estado durante la ejecución del destino. La ejecución del destino y el valor de cualquier %-expressions contenidas en él también depende del procesamiento por lotes del destino y también puede desencadenar el procesamiento por lotes; consulte de procesamiento por lotes de MSBuild.
Los siguientes elementos admiten el atributo Condition:
- Importación
- ImportGroup
- Artículo
- ItemDefinitionGroup
- ItemGroup
- ItemMetadata
- OnError
- Salida
- Propiedad
- PropertyGroup
- Blanco
- Tarea
- UsingTask
- Cuando