Freigeben über


Anpassen des lokalen Builds

Wenn Sie mit freigegebenem Code in einem Code-Repository wie GitHub, in der Quellcodeverwaltung oder mit einer beliebigen freigegebenen Codebasis arbeiten, können Sie MSBuild verwenden, um Builds auf Ihrem lokalen Computer vorübergehend anzupassen. Möglicherweise möchten Sie vorübergehend einen Fehler reproduzieren oder eine andere Konfiguration testen und diese Anpassungen getrennt von den Dateien im freigegebenen Code-Repository beibehalten. In diesem Artikel werden einige Builderweiterungen in MSBuild beschrieben, mit denen Sie benutzerspezifische oder lokale benutzerdefinierte Buildkonfigurationen erstellen können.

Voraussetzungen

  • Ein Visual Studio-Projekt, das mit MSBuild erstellt wird.

Benutzerdatei verwenden

Sie können $(MSBuildProjectFullPath).user, das in diesem Kontext auch als Benutzerdatei bezeichnet wird, verwenden, um Erweiterungen, Optionen oder Variablen zu speichern, die für Ihren lokalen Computer spezifisch sind. Die Benutzerdatei ist nicht dafür vorgesehen, in die Versionskontrolle hochgeladen zu werden, und wird automatisch auf .gitignore überprüft. Für umfangreichere Änderungen ändern Sie das Projekt selbst, sodass zukünftige Betreuer diesen Erweiterungsmechanismus nicht kennen müssen.

Bei unterstützten multitargetierten Projekten wird die Benutzerdatei automatisch in inneren Builds und äußeren Builds importiert, sodass Sie diese Datei innerhalb der Lösung erstellen können. Wenn Sie an einem anderen Buildtyp arbeiten, können Sie die Benutzerdatei verwenden, indem Sie sie in Ihrer Projektmappe erstellen und dann wie folgt in Ihre Projektdatei importieren:

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

Verwenden von MSBuildExtensionsPath und MSBuildUserExtensionsPath

Üblicherweise importieren viele Kern-Buildlogikdateien die Datei $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportBefore\*.targets vor ihrem Inhalt und danach die Datei $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportAfter\*.targets. Diese Konvention ermöglicht es installierten SDKs, die Buildlogik allgemeiner Projekttypen zu erweitern.

Die gleiche Verzeichnisstruktur wird in $(MSBuildUserExtensionsPath) durchsucht, wobei es sich um den pro Benutzer spezifischen Ordner %LOCALAPPDATA%\Microsoft\MSBuild handelt. Dateien, die in diesem Ordner gespeichert sind, werden für alle Builds des entsprechenden Projekttyps importiert, die unter den Anmeldeinformationen dieses Benutzers ausgeführt werden.

Sie können die Benutzererweiterungen deaktivieren, indem Sie im Muster ImportUserLocationsByWildcardBefore\<ImportingFileNameWithNoDots>Eigenschaften festlegen, die nach der importdatei benannt sind. Beispielsweise verhindert die Einstellung von ImportUserLocationsByWildcardBeforeMicrosoftCommonProps auf false den Import von $(MSBuildUserExtensionsPath\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*.

Erstellen von benutzerdefinierten Bedingungen basierend auf der Projektsprache

Wenn Sie je nach .NET-Sprache unterschiedliche Verhaltensweisen benötigen: C#, Visual Basic oder F#, können Sie Eigenschaftengruppen mit Bedingungen hinzufügen, die von der Projektdateierweiterung <MSBuildProjectExtension> abhängig sind, um sprachspezifische Eigenschaften und deren Werte zu definieren.

<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>