Share via

Anpassen des lokalen Builds

  • Artikel

Wenn Sie in einem Team arbeiten, das ein Coderepository wie GitHub, die Quellcodeverwaltung oder eine gemeinsam genutzte Codebasis verwendet hat, Sie Ihre Builds aber auf Ihrem lokalen Computer anpassen möchten (möglicherweise nur vorübergehend, um einen Fehler zu reproduzieren oder eine andere Konfiguration zu testen), kann es sinnvoll sein, diese Anpassungen von den Projektdateien getrennt zu halten, die für das gemeinsame Coderepository freigegeben werden. In diesem Artikel werden einige in MSBuild verfügbare Builderweiterungen beschrieben, mit denen Sie benutzerspezifische oder ausschließlich lokale benutzerdefinierte Konfigurationen vornehmen können.

USER-Datei

Die Verwendung von $(MSBuildProjectFullPath).user, in diesem Kontext auch als .user-Datei bezeichnet, ist auch eine Option. Diese Datei soll Erweiterungen, Optionen oder Variablen beibehalten, die für Ihren lokalen Computer spezifisch sind. Sie ist nicht für das Hochladen in die Quellcodeverwaltung vorgesehen und wird automatisch auf .gitignore überprüft. Für umfangreichere Änderungen ist es bevorzugt, das Projekt selbst zu ändern, damit zukünftige Betreuer diesen Erweiterungsmechanismus nicht kennen müssen.

Bei unterstützten multitargeted Projekten wird die .user-Datei automatisch in innere und äußere Builds importiert, sodass Sie die Datei einfach innerhalb der Lösung erstellen können. Wenn Sie an einem anderen Buildtyp arbeiten, können Sie die .user-Datei weiterhin verwenden. Sie können sie in Ihrer Projektmappe erstellen und dann in Ihrer Projektdatei importieren.

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

MSBuildExtensionsPath und MSBuildUserExtensionsPath

Standardmäßig importieren viele wichtige Buildlogikdateien

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

vor ihrem Inhalt und

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

danach. Dank dieser Konvention können installierte SDKs die Buildlogik häufig verwendeter Projekttypen erweitern.

In $(MSBuildUserExtensionsPath) wird nach der gleichen Verzeichnisstruktur (je nach Benutzerordner %LOCALAPPDATA%\Microsoft\MSBuild) gesucht. Dateien, die in diesem Ordner platziert werden, werden für alle Builds des jeweiligen Projekttyps importiert, die mit den Anmeldeinformationen des Benutzers ausgeführt werden. Sie können die Benutzererweiterungen deaktivieren, indem Sie die Eigenschaften festlegen, die nach der Importdatei im Muster ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots} benannt werden. Wenn Sie beispielsweise ImportUserLocationsByWildcardBeforeMicrosoftCommonProps auf false festlegen, wird $(MSBuildUserExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\* nicht importiert.

Benutzerdefinierte Konfiguration auf Basis der Projektsprache

Wenn Sie abhängig von der .NET-Programmiersprache (C#, Visual Basic oder F#) unterschiedliche Verhaltensweisen benötigen, können Sie Eigenschaftengruppen mit Bedingungen hinzufügen, die von der Projektdateierweiterung in $(MSBuildProjectExtension) abhängen, 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>

Zugehöriger Inhalt