Personnaliser votre build locale
Si vous travaillez dans une équipe qui utilise un dépôt de code comme GitHub, un contrôle de code source ou un codebase partagé et que vous souhaitez personnaliser vos builds sur votre ordinateur local, par exemple pour reproduire un bogue ou tester une configuration différente de manière temporaire, il peut être judicieux de séparer ces personnalisations des fichiers projet qui sont partagés avec le dépôt de code partagé. Cet article décrit certaines extensions de build disponibles dans MSBuild qui vous permettent de créer des configurations personnalisées spécifiques à l’utilisateur ou locales uniquement.
Fichier .user
Il est également possible d’utiliser $(MSBuildProjectFullPath).user, également appelé fichier .user dans ce contexte. Ce fichier est destiné à conserver des extensions, des options ou des variables spécifiques à votre ordinateur local. Il n’est pas destiné à être chargé dans le contrôle de code source, et il est automatiquement vérifié dans .gitignore. Pour des modifications plus étendues, préférez la modification du projet proprement dit, afin que les futurs responsables de la maintenance n’aient pas à connaître ce mécanisme d’extension.
Sur les projets multicibles pris en charge, le fichier .user est automatiquement importé dans les builds internes et les builds externes. Vous pouvez donc simplement créer le fichier dans la solution. Si vous travaillez sur un autre type de build, vous pouvez toujours utiliser le fichier .user. Vous pouvez le créer dans votre solution, puis l’importer dans votre fichier projet.
<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>
MSBuildExtensionsPath et MSBuildUserExtensionsPath
Par convention, de nombreux fichiers de logique de génération de base importent
$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportBefore\*.targets
avant leur contenu, et
$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportAfter\*.targets
après. Avec cette convention, les kits SDK installés peuvent renforcer la logique de génération des types de projets courants.
La même structure de répertoires fait l’objet d’une recherche dans $(MSBuildUserExtensionsPath), qui est le dossier par utilisateur %LOCALAPPDATA%\Microsoft\MSBuild. Les fichiers placés dans ce dossier sont importés pour toutes les générations du type de projet correspondant exécutées sous les informations d’identification de l’utilisateur concerné. Vous pouvez désactiver les extensions utilisateur en définissant les propriétés nommées d’après le fichier d’importation selon le modèle ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots}. Par exemple, si vous définissez ImportUserLocationsByWildcardBeforeMicrosoftCommonProps avec la valeur false, vous empêchez l’importation de $(MSBuildUserExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*.
Configuration personnalisée en fonction du langage du projet
Si vous avez besoin de comportements différents en fonction du langage .NET (C#, Visual Basic ou F#), vous pouvez ajouter des groupes de propriétés contenant des conditions qui dépendent de l’extension de fichier projet dans $(MSBuildProjectExtension) pour définir des propriétés propres au langage et leurs valeurs.
<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>