Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
MSBuild Server verbessert die Leistung von .NET Core-Builds, die aufgerufen werden, wenn Sie den dotnet build Befehl aus der .NET CLI auf Windows, Linux oder Mac .NET Core-Buildumgebungen verwenden. Anstatt den Buildprozess jedes Mal zu starten, wenn ein Build angefordert wird, wird ein Großteil des Kontexts in einem lang ausgeführten Prozess zwischengespeichert, damit er vom nächsten Build wiederverwendet werden kann. MSBuild Server ist für Visual Studio Builds nicht relevant, da Visual Studio als Host für MSBuild fungiert und bereits den gesamten erforderlichen Kontext zwischenspeichert.
MSBuild Server ist in CI-Szenarien wie z. B. Azure Pipelinebuilds im Allgemeinen nicht hilfreich, da Pipelines in der Regel eine Buildumgebung bei Bedarf für jeden Build aufstellen und diese dann entsorgen, wenn der Build abgeschlossen ist.
Aktivieren von MSBuild Server
Ab dem .NET 11 SDK ist der MSBuild Server für MSBuild-basierte .NET CLI-Befehle wie dotnet build und dotnet msbuild standardmäßig aktiviert.
In früheren .NET SDKs war MSBuild Server standardmäßig deaktiviert und wurde durch Festlegen von DOTNET_CLI_USE_MSBUILD_SERVER auf true oder 1 aktiviert.
Wenn Sie einen Build zum ersten Mal starten, wird der Buildserver gestartet, und der Cache wird aufgefüllt. Der Cache wird nach Abschluss dieses Builds beibehalten. Der zweite Build wird daher schneller fortgesetzt, da die Startzeit aufgrund der zwischengespeicherten Informationen erheblich reduziert wird. Der Cache wird nach Abschluss des Builds beibehalten, aber nach einer Leerlaufzeit von 15 Minuten wird der Server heruntergefahren. Daher ist es in erster Linie vorteilhaft bei sich wiederholenden Buildszenarien, in denen viele Builds in enger Folge angefordert werden.
MSBuild Server wird auch automatisch für Multithread-Builds (-mt) verwendet, da die multithreadige Ausführung Projektarbeit im Serverprozess ausführt.
Herunterfahren oder Deaktivieren von MSBuild Server
Es gibt einige verschiedene Möglichkeiten, die Verwendung des MSBuild-Servers zu deaktivieren. Wenn Sie nur den ausgeführten Server herunterfahren möchten, können Sie den Befehl dotnet build-server shutdownausgeben.
Um das Feature für alle Builds auf einem Computer zu deaktivieren, können Sie die Systemumgebungsvariable DOTNET_CLI_USE_MSBUILD_SERVER auf falsefestlegen. Sie können diese Variable auch für jedes Projekt in einem Tool wie VS Code in launch.json festlegen.
Um MSBuild Server für einen bestimmten Aufruf eines Befehlszeilenbuilds zu deaktivieren, können Sie die Option /nr:false (oder /node-reuse:false) verwenden. MSBuild Server ist eine Form der Wiederverwendung von Knoten, sodass das Deaktivieren der Knotenwiederverwendung auch den Server deaktiviert und der Build im Startvorgang ausgeführt wird.
MSBuild Server wird nicht für Aufrufe verwendet, die inhärent nicht mit der Ausführung des Builds in einem separaten Prozess kompatibel sind, wie z. B. -help, -version und das erneute Abspielen eines Binärprotokolls. Diese Builds greifen als Fallback auf die Ausführung im Startprozess zurück.
Ermitteln des aktuellen Status des Buildservers
Sie können den Prozessstatus auf dem Computer anzeigen und nach MSBuild-Serverprozessen suchen. MSBuild-Serverprozesse werden mit dotnet.exe gestartet und zeigen den Pfad zu MSBuild.dll sowie die Befehlszeilenoption /nodemode:8, wobei 8 den MSBuild-Server kennzeichnet (/nodemode:1 kennzeichnet die normalen MSBuild-Workerknoten).
Builds, die MSBuild Server anfordern, zeichnen außerdem auf, was damit geschieht. Führen Sie eine Ausführung mit -v:diagoder erfassen Sie ein binäres Protokoll mit -bl, um festzustellen, ob der Build einen neuen Server startet, einen ausgeführten Server wiederverwendet oder auf einen In-Process-Build zurückfällt und warum.