Compartir a través de


Personalización de la compilación local

Cuando trabaja en un equipo que ha usado un repositorio de código como GitHub, control de código fuente o cualquier código base compartido, pero quiere personalizar las compilaciones en la máquina local, puede que de forma temporal para reproducir un error o probar una configuración distinta, puede ser conveniente mantener esas personalizaciones separadas de los archivos de proyectos compartidos que se comparten con el repositorio de código compartido. En este artículo se describen algunas extensiones de compilación disponibles en MSBuild que permiten realizar configuraciones personalizadas específicas del usuario o solo locales.

El archivo .user

El uso de $(MSBuildProjectFullPath).user, también conocido como archivo .user en este contexto, también es una opción. Este archivo está diseñado para mantener extensiones, opciones o variables específicas de la máquina local. No está diseñado para cargarse en el control de código fuente y se comprueba automáticamente en .gitignore. Para cambios más extensos es preferible cambiar el propio proyecto, para que los futuros mantenedores no tengan que conocer este mecanismo de ampliación.

En los proyectos multidestino compatibles, el archivo de .user se importa automáticamente en las compilaciones internas y externas, por lo que basta con crear el archivo dentro de la solución. Si está trabajando en otro tipo de compilación, puede seguir usando el archivo .user. Puede crearlo en la solución y, a continuación, importarlo en el archivo del proyecto.

<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>

MSBuildExtensionsPath y MSBuildUserExtensionsPath

Por convención, muchos archivos de lógica de compilación principales importan

$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportBefore\*.targets

antes de su contenido, y

$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportAfter\*.targets

después. Esta convención permite que los SDK instalados aumenten la lógica de compilación de los tipos de proyecto comunes.

Se busca la misma estructura de directorios en $(MSBuildUserExtensionsPath), que es la carpeta %LOCALAPPDATA%\Microsoft\MSBuild por usuario. Los archivos ubicados en esa carpeta se importarán para todas las compilaciones del tipo de proyecto correspondiente que se ejecuta con las credenciales del usuario. Puede deshabilitar las extensiones de usuario si establece propiedades con el mismo nombre que el archivo de importación con el patrón ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots}. Por ejemplo, si se establece ImportUserLocationsByWildcardBeforeMicrosoftCommonProps en false se impedirá la importación de $(MSBuildUserExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*.

Configuración personalizada basada en el lenguaje del proyecto

Si necesita comportamientos diferentes en función del lenguaje .NET (C#, Visual Basic o F#), puede agregar grupos de propiedades con condiciones que dependan de la extensión de archivo del proyecto en $(MSBuildProjectExtension) para definir propiedades específicas del lenguaje y sus valores.

<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.vbproj'">
   <!-- Put VB-only property definitions here -->
</PropertyGroup>
<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.fsproj'">
   <!-- Put F#-only property definitions here -->
</PropertyGroup>
<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.csproj'">
   <!-- Put C#-only property definitions here -->
</PropertyGroup>