msbuild nuget stylecop

El misterio de los procesos pegados inactivos de msbuild.exe, Stylecop.dll bloqueado, Nuget AccessViolationException y las compilaciones de CI que chocan entre sí



(2)

Después de investigar mucho y probar varias cosas sin ningún resultado, finalmente terminé creando una nueva solución mínima que reprodujo el problema con muy poco más. El problema se debió a la paralelización de múltiples núcleos de msbuild: el parámetro ''m''.

  • El parámetro ''m'' le dice a msbuild que engendre "nodos", estos permanecerán vivos después de que la construcción haya terminado, ¡y luego serán reutilizados por nuevas compilaciones!
  • El error "ViolationCount" de StyleCop fue causado por una compilación dada que reutilizaba una versión anterior de stylecop.dll del espacio de trabajo de otra compilación, donde ViolationCount no era compatible. Esto fue extraño, porque el espacio de trabajo de CI solo contenía la nueva versión. Parece que una vez que se cargó el StyleCop.dll en un nodo MsBuild determinado, se mantendría cargado para la siguiente compilación. Solo puedo suponer que esto se debe a que StyleCop carga algún tipo de singleton en los procesos de los nodos. Esto también explica el bloqueo de archivos entre compilaciones.
  • El bloqueo de violación de acceso nuget se ha ido (sin ningún otro cambio), por lo que está evidentemente relacionado con el problema de reutilización del nodo anterior.
  • Como el parámetro ''m'' se establece por defecto en la cantidad de núcleos, estábamos viendo 24 instancias de msbuild creadas en nuestro servidor de compilación para un trabajo determinado.

Las siguientes publicaciones fueron útiles:

La solución:

  • Agregue el set MSBUILDDISABLENODEREUSE=1 líneas set MSBUILDDISABLENODEREUSE=1 al archivo de proceso por lotes que inicia msbuild
  • Inicie msbuild con /m:4 /nr:false
  • El parámetro ''nr'' le dice a msbuild que no use "Reutilización de nodos", por lo que las instancias de msbuild se cierran después de que la compilación se completa y ya no entran en conflicto entre sí, lo que da como resultado los errores anteriores.
  • El parámetro ''m'' se establece en 4 para detener demasiados nodos que se generan por trabajo

Observaciones:

  • En nuestro servidor de compilación de Jenkins, estábamos viendo muchos procesos msbuild.exe (~ 100) dando vueltas después de la finalización del trabajo con alrededor de 20 MB de uso de memoria y 0% de actividad de la CPU.

  • Las compilaciones con diferentes versiones de stylecop fallaban intermitentemente :

    workspace/packages/StyleCop.MSBuild.4.7.41.0/tools/StyleCop.targets(109,7): error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task. Verify the parameter exists on the task, and it is a gettable public instance property.

  • Nuget.exe salió de forma intermitente con el siguiente error de infracción de acceso (0x0000005):

    ./workspace/.nuget/nuget install ./workspace/packages.config -o ./workspace/packages" exited with code -1073741819.

MsBuild se lanzó de la siguiente manera a través de un trabajo de Matrix Jenkins, con ''BuildInParallel'' habilitado:

`msbuild /t:%Targets% /m /p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%; JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%; Clean=%Clean%; %~dp0/_Jenkins/Build.proj`

Tuve el mismo problema. Una antigua referencia que encontré estaba en archivos csproj

<PropertyGroup> <StyleCopMSBuildTargetsFile>../packages/StyleCop.MSBuild.4.7.48.0/tools/StyleCop.targets</StyleCopMSBuildTargetsFile>

Además, eliminé toda la carpeta "Paquetes" que se encuentra en la misma carpeta que el archivo sln después de cerrar el estudio visual. Se activó VS para reconstruir la carpeta y soltar el caché de la versión anterior de stylecop