Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous utilisez du code partagé dans un référentiel de code tel que GitHub, dans le contrôle de code source ou avec n’importe quelle base de code partagée, vous pouvez utiliser MSBuild pour personnaliser temporairement les builds sur votre ordinateur local. Vous pouvez reproduire temporairement un bogue ou tester une configuration différente et séparer ces personnalisations des fichiers du référentiel de code partagé. Cet article décrit certaines extensions de build disponibles dans MSBuild qui vous permettent de créer des configurations de build personnalisées spécifiques à l’utilisateur ou locales uniquement.
Conditions préalables
- Projet Visual Studio qui s’génère avec MSBuild.
Utiliser le fichier utilisateur
Vous pouvez utiliser $(MSBuildProjectFullPath).user, également appelé fichier utilisateur dans ce contexte, pour stocker des extensions, des options ou des variables spécifiques à votre ordinateur local. Le fichier utilisateur n’est pas destiné à être téléversé dans la gestion de versions et est automatiquement vérifié .gitignore. Pour des modifications plus approfondies, modifiez le projet lui-même, de sorte que les responsables futurs n’ont pas à connaître ce mécanisme d’extension.
Sur les projets multi-cibles pris en charge, le fichier utilisateur est automatiquement importé dans les builds internes et les builds externes. Vous pouvez donc créer ce fichier dans la solution. Si vous travaillez sur un autre type de build, vous pouvez utiliser le fichier utilisateur en le créant dans votre solution, puis en l’important dans votre fichier projet, comme suit :
<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>
Utiliser MSBuildExtensionsPath et MSBuildUserExtensionsPath
Par convention, de nombreux fichiers logiques de génération de base importent le $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportBefore\*.targets fichier avant leur contenu et le $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportAfter\*.targets fichier ensuite. Cette convention permet aux kits SDK installés d’augmenter la logique de génération des types de projets courants.
La même structure de répertoires est recherchée dans $(MSBuildUserExtensionsPath), qui est le dossier par utilisateur %LOCALAPPDATA%\Microsoft\MSBuild. Les fichiers placés dans ce dossier sont importés pour toutes les builds du type de projet correspondant exécutés sous les informations d’identification de cet utilisateur.
Vous pouvez désactiver les extensions utilisateur en définissant des propriétés nommées après le fichier d’importation, dans le modèle ImportUserLocationsByWildcardBefore\<ImportingFileNameWithNoDots>. Par exemple, paramétrer ImportUserLocationsByWildcardBeforeMicrosoftCommonProps à false empêche l'importation $(MSBuildUserExtensionsPath\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*.
Créer des conditions personnalisées 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 avec des conditions qui dépendent de l’extension de fichier projet dans <MSBuildProjectExtension> laquelle définir des propriétés spécifiques 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>