Тайна запущенных неактивных процессов msbuild.exe, заблокированных файлов Stylecop.dll, Nuget AccessViolationException и CI, сталкиваются друг с другом

замечания:

На нашем сервере сборки Jenkins мы наблюдали много процессов msbuild.exe(~ 100), зависающих после завершения работы с использованием памяти 20 МБ и 0% активности процессора.
Сборка с использованием разных версий стильной машины прерывалась с ошибкой:

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 периодически прерывался со следующей ошибкой нарушения прав доступа (0x0000005):

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

MsBuild был запущен следующим образом через задание матрицы Jenkins, с включенным "BuildInParallel":

    `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`

Ответ 1

После долгих разрастаний и попыток разного рода действий я в конечном итоге закончил создание нового минимального решения, которое воспроизвело проблему с очень небольшим продолжением. Проблема оказалась вызвана многоядерной параллелизацией msbuild - параметром "m".

Параметр "m" указывает msbuild на "узлы", они останутся в живых после завершения сборки и затем снова будут использованы новыми сборками!
Ошибка StyleCop 'ViolationCount' была вызвана тем, что данная сборка повторно использовала старую версию stylecop.dll из другого рабочего пространства сборки, где ViolationCount не поддерживался. Это было странно, потому что рабочее пространство CI содержало только новую версию. Похоже, что когда StyleCop.dll был загружен в данный MsBuild node, он останется загруженным для следующей сборки. Я могу только предположить, что это связано с тем, что StyleCop загружает какой-то одноэлемент в процессы узлов? Это также объясняет блокировку файлов между сборками.
Теперь произошел сбой в доступе к доступу к nuget (без каких-либо изменений), поэтому, очевидно, связано с проблемой повторного использования node.
По умолчанию для параметра "m" задано количество ядер - мы видели 24 экземпляра msbuild, созданных на нашем сервере сборки для заданного задания.

Следующие сообщения были полезны:

Исправление:

Добавьте строку set MSBUILDDISABLENODEREUSE=1 в пакетный файл, который запускает msbuild
Запустите msbuild с помощью /m:4 /nr:false
Параметр 'nr' указывает msbuild не использовать "Node Reuse" - поэтому экземпляры msbuild закрываются после завершения сборки и больше не сталкиваются друг с другом, что приводит к вышеуказанным ошибкам.
Параметр "m" установлен в 4, чтобы остановить слишком много нерестовых узлов для каждого задания.

Ответ 2

У меня была такая же проблема. Одна старая ссылка, которую я нашел, была в файлах csproj.

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

Кроме того, я удалил всю папку "Пакеты", расположенную в той же папке, что и sln файл, после того как я закрыл визуальную студию. Это заставило VS перестроить папку и отпустить кеш старой версии stylecop