Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Program MSBuild Server zwiększa wydajność kompilacji .NET Core, które są wywoływane podczas użycia polecenia dotnet build z interfejsu CLI .NET w środowiskach kompilacji .NET Core na systemach Windows, Linux lub Mac. Zamiast uruchamiać proces kompilacji za każdym razem, gdy jest wymagane utworzenie kompilacji, większość kontekstu jest buforowana w długotrwałym procesie, więc jest dostępna do ponownego użycia przez następną kompilację. Program MSBuild Server nie jest odpowiedni dla kompilacji programu Visual Studio, ponieważ program Visual Studio działa jako host programu MSBuild i buforuje wszystkie niezbędne konteksty.
Serwer MSBuild zwykle nie jest pomocny w scenariuszach CI (ciągłej integracji), takich jak kompilacje Azure Pipeline, ponieważ pipeline zazwyczaj tworzy środowisko kompilacji na żądanie dla każdej kompilacji, a następnie usuwa je po zakończeniu kompilacji.
Włączanie programu MSBuild Server
Począwszy od zestawu SDK .NET 11, program MSBuild Server jest domyślnie włączony dla poleceń interfejsu wiersza polecenia .NET opartych na programie MSBuild, takich jak dotnet build i dotnet msbuild.
We wcześniejszych zestawach SDK .NET program MSBuild Server był domyślnie wyłączony i włączono go przez ustawienie DOTNET_CLI_USE_MSBUILD_SERVER na true lub 1.
Po pierwszym uruchomieniu kompilacji serwer kompilacji jest uruchamiany i wypełniana jest pamięć podręczna. Pamięć podręczna jest utrwalana po zakończeniu tej kompilacji; w związku z tym druga kompilacja przebiega szybciej, ponieważ czas uruchamiania jest znacznie krótszy z powodu buforowanych informacji. Pamięć podręczna pozostaje zachowana po zakończeniu kompilacji, ale po 15 minutach bezczynności serwer zostanie wyłączony. W związku z tym jest to przede wszystkim korzystne w powtarzających się scenariuszach kompilacji, w których wiele kompilacji jest wymaganych w bliskim odstępie czasu.
Program MSBuild Server jest również automatycznie zaangażowany w kompilacje wielowątkowane (-mt), ponieważ wykonywanie wielowątkowe uruchamia pracę projektu wewnątrz procesu serwera.
Zamykanie lub wyłączanie programu MSBuild Server
Istnieje kilka różnych sposobów wyłączania korzystania z serwera MSBuild. Jeśli chcesz tylko zamknąć uruchomiony serwer, możesz wydać polecenie dotnet build-server shutdown.
Aby wyłączyć tę funkcję we wszystkich kompilacjach na danym komputerze, możesz ustawić systemową zmienną środowiskową DOTNET_CLI_USE_MSBUILD_SERVER na false. Tę zmienną można również ustawić dla poszczególnych projektów w narzędziu takim jak VS Code w launch.json.
Aby wyłączyć MSBuild Server dla konkretnego wywołania kompilacji z wiersza poleceń, możesz użyć opcji /nr:false (lub /node-reuse:false). MSBuild Server jest mechanizmem ponownego użycia węzłów, więc wyłączenie ponownego użycia węzłów powoduje również wyłączenie serwera, a kompilacja jest uruchamiana w procesie wywołującym.
Program MSBuild Server nie jest używany do wywołań, które z natury są niezgodne z uruchomieniem kompilacji w osobnym procesie, takich jak -help, -version i odtwarzanie dziennika binarnego. Kompilacje te wracają do działania w procesie uruchamiania.
Określanie bieżącego stanu serwera kompilacji
Stan procesu można wyświetlić na maszynie i wyszukać procesy serwera MSBuild. pl-PL: Procesy serwera MSBuild są uruchamiane za pomocą dotnet.exe, pokazują ścieżkę do MSBuild.dll i opcję /nodemode:8, gdzie 8 wskazuje serwer MSBuild ( /nodemode:1 wskazuje normalne węzły robocze MSBuild).
Kompilacje, które żądają programu MSBuild Server, rejestrują również, co się z nim dzieje. Uruchom za pomocą -v:diag, lub przechwyć dziennik binarny za pomocą -bl, aby sprawdzić, czy kompilacja uruchamia nowy serwer, ponownie używa już uruchomionego serwera, czy przechodzi do kompilacji w procesie, oraz dlaczego.
Zobacz także
- zbuduj dotnet
- MSBuild