Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al trabajar con código compartido en un repositorio de código como GitHub, en el control de código fuente o con cualquier código base compartido, puede usar MSBuild para personalizar temporalmente las compilaciones en el equipo local. Es posible que quiera reproducir temporalmente un error o probar una configuración diferente y mantener esas personalizaciones separadas de los archivos del repositorio de código compartido. En este artículo se describen algunas extensiones de compilación disponibles en MSBuild que permiten configurar configuraciones de compilación personalizadas específicas del usuario o solo local.
Prerrequisitos
- Un proyecto de Visual Studio que se compila con MSBuild.
Uso del archivo de usuario
También puede usar $(MSBuildProjectFullPath).user, denominado archivo de usuario en este contexto, para almacenar extensiones, opciones o variables específicas de la máquina local. El archivo de usuario no está pensado para cargarse en el control de código fuente y se comprueba automáticamente en .gitignore. Para realizar cambios más amplios, cambie el propio proyecto, por lo que los futuros mantenedores no tienen que saber sobre este mecanismo de extensión.
En los proyectos de varios destinos admitidos, el archivo de usuario se importa automáticamente en compilaciones internas y compilaciones externas, por lo que puede crear este archivo dentro de la solución. Si está trabajando en otro tipo de compilación, puede usar el archivo de usuario mediante su creación en la solución y, a continuación, importarlo en el archivo de proyecto, como se indica a continuación:
<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>
Uso de MSBuildExtensionsPath y MSBuildUserExtensionsPath
Por convención, muchos archivos lógicos de compilación principales importan el $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportBefore\*.targets archivo antes de su contenido y el $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportAfter\*.targets archivo después. Esta convención permite que los SDK instalados aumenten la lógica de compilación de tipos de proyecto comunes.
Se busca en la misma estructura de directorios en $(MSBuildUserExtensionsPath), que es la carpeta por usuario %LOCALAPPDATA%\Microsoft\MSBuild. Los archivos colocados en esa carpeta se importan para todas las compilaciones del tipo de proyecto correspondiente que se ejecutan con las credenciales de ese usuario.
Puede deshabilitar las extensiones de usuario estableciendo propiedades denominadas después del archivo de importación, en el patrón ImportUserLocationsByWildcardBefore\<ImportingFileNameWithNoDots>. Por ejemplo, al establecer ImportUserLocationsByWildcardBeforeMicrosoftCommonProps para false evitar la importación $(MSBuildUserExtensionsPath\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*de .
Creación de condiciones personalizadas basadas 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 dependen 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>