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

замечания:

  • на нашем сервере сборки Jenkins мы видели много msbuild.exe процессы (~100) висит вокруг после завершения задания с использованием около 20 Мб памяти и 0% активности процессора.

  • сборки с использованием различных версий stylecop были периодически не работает:

    workspacepackagesStyleCop.MSBuild.4.7.41.0toolsStyleCop.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.nugetnuget install .workspacepackages.config -o .workspacepackages" exited with code -1073741819.

MsBuild был запущен следующим образом через задание матрицы Дженкинса с включенным параметром' 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_JenkinsBuild.proj`
2 51
msbuild nuget stylecop

2 ответа:

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

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

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

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

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

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

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

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

1