Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
MSBuild Server mejora el rendimiento de las compilaciones de .NET Core, que se invocan al usar el dotnet build comando desde la CLI de .NET en entornos de compilación de Windows, Linux o Mac .NET Core. En lugar de iniciar el proceso de compilación cada vez que se solicita una compilación, gran parte del contexto se almacena en caché en un proceso de ejecución prolongada, por lo que está disponible para que la próxima compilación lo reutilice. MsBuild Server no es relevante para Visual Studio compilaciones, ya que Visual Studio actúa como host para MSBuild y ya almacena en caché todo el contexto necesario.
Por lo general, el servidor de MSBuild no es útil en escenarios de CI como compilaciones de canalización de Azure, ya que las canalizaciones suelen soportar un entorno de compilación a petición para cada compilación y, a continuación, eliminarlo cuando se complete la compilación.
Habilitación del servidor de MSBuild
A partir del SDK de .NET 11, MSBuild Server está habilitado de forma predeterminada para comandos de la CLI de .NET basados en MSBuild, como dotnet build y dotnet msbuild.
En versiones anteriores del SDK de .NET, el servidor de MSBuild estaba desactivado de forma predeterminada y se habilitaba estableciendo DOTNET_CLI_USE_MSBUILD_SERVER en true o 1.
La primera vez que inicie una compilación, se inicia el servidor de compilación y se rellena la memoria caché. La memoria caché se conserva después de la finalización de esa compilación; Por lo tanto, la segunda compilación continúa más rápido, ya que el tiempo de inicio se reduce significativamente debido a la información almacenada en caché. La memoria caché persiste una vez completada la compilación, pero después de un tiempo de inactividad de 15 minutos, el servidor se apaga. Por lo tanto, resulta especialmente beneficioso en escenarios con compilaciones repetidas donde se solicitan muchas compilaciones con poco intervalo entre sí.
MSBuild Server también se activa automáticamente para compilaciones multihilo (-mt), ya que la ejecución multihilo ejecuta el trabajo del proyecto dentro del proceso del servidor.
Apagar o deshabilitar el servidor de MSBuild
Hay varias maneras diferentes de deshabilitar el uso del servidor de MSBuild. Si solo desea apagar el servidor en ejecución, puede emitir el comando dotnet build-server shutdown.
Para deshabilitar la función en todas las compilaciones de una máquina, puede establecer la variable de entorno del sistema DOTNET_CLI_USE_MSBUILD_SERVER en false. También puede establecer esta variable por proyecto en una herramienta como VS Code en launch.json.
Para deshabilitar el servidor de MSBuild para una invocación determinada de una compilación de línea de comandos, puede usar la opción /nr:false (o /node-reuse:false). MSBuild Server es una forma de reutilización de nodos, por lo que deshabilitar la reutilización de nodos también deshabilita el servidor y la compilación se ejecuta en el proceso de inicio.
MsBuild Server no se usa para las invocaciones que son inherentemente incompatibles con el hospedaje de la compilación en un proceso independiente, como -help, -versiony la reproducción de un registro binario. Esas compilaciones recurren a ejecutarse en el proceso de inicio.
Determinar el estado actual del servidor de compilación
Puede ver el estado del proceso en la máquina y buscar los procesos del servidor de MSBuild. Los procesos de servidor de MSBuild se inician con dotnet.exe y muestran una ruta de acceso a MSBuild.dll y la opción /nodemode:8de comando , donde 8 indica el servidor de MSBuild ( /nodemode:1 indica los nodos de trabajo normales de MSBuild).
Las compilaciones que solicitan el servidor de MSBuild también registran lo que le sucede. Ejecute con -v:diag, o capture un registro binario con -bl, para ver si la compilación inicia un nuevo servidor, reutiliza una en ejecución o vuelve a una compilación en proceso y por qué.