web-dev-qa-db-ja.com

スタックした非アクティブなmsbuild.exeプロセス、ロックされたStylecop.dll、Nuget AccessViolationException、およびCIビルドの衝突の謎

観察:

  • Jenkinsビルドサーバーでは、ジョブの完了後に多くのmsbuild.exeプロセス(〜100)が約20 MBのメモリ使用量と0%のCPUアクティビティでぶらぶらしていました。

  • Stylecopの異なるバージョンを使用したビルドは断続的に失敗しました:

    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は、「BuildInParallel」を有効にして、Jenkins Matrixジョブを介して次の方法で起動されました。

    `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`
59
Jon Rea

lotを掘り下げてさまざまなことを効果的に試みた後、私は最終的に問題を再現する新しい最小限のソリューションを作成しました。オン。この問題は、msbuildのマルチコア並列化(「m」パラメーター)が原因であることが判明しました。

  • 「m」パラメータは、msbuildに「ノード」を生成するように指示します。これらは、ビルドの終了後も存続し、新しいビルドで再利用されます。
  • StyleCop 'ViolationCount'エラーは、特定のビルドが、ViolationCountがサポートされていない別のビルドのワークスペースからstylecop.dllの古いバージョンを再使用することによって発生しました。 CIワークスペースには新しいバージョンのみが含まれていたため、これは奇妙でした。 StyleCop.dllが特定のMsBuildノードにロードされると、次のビルドまでロードされたままになるようです。これは、StyleCopがノードプロセスに何らかのシングルトンをロードするためだと推測できますか?また、ビルド間のファイルロックについても説明します。
  • Nugetアクセス違反のクラッシュは(他の変更なしで)なくなったため、上記のノードの再利用の問題と明らかに関係しています。
  • 「m」パラメータのデフォルトはコアの数です-ビルドサーバー上で特定のジョブ用に作成された24msbuildインスタンスが表示されていました。

次の投稿は役に立ちました。

修正:

  • Msbuildを起動するバッチファイルにset MSBUILDDISABLENODEREUSE=1行を追加します
  • /m:4 /nr:falseでmsbuildを起動します
  • 「nr」パラメータは、msbuildに「ノードの再利用」を使用しないように指示します。したがって、msbuildインスタンスは、ビルドの完了後に閉じられ、互いに衝突することはなくなり、上記のエラーが発生します。
  • 「m」パラメーターは4に設定され、ジョブごとにスポーンするノードが多くなりすぎないようにします。
71
Jon Rea

同じ問題がありました。私が見つけた1つの古い参照はcsprojファイルにありました

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

また、Visual Studioを閉じた後、slnファイルと同じフォルダーにある「Packages」フォルダー全体を削除しました。 VSをトリガーしてフォルダーを再構築し、stylecopの古いバージョンのキャッシュを解放しました

1
Jin

私はしばらくの間同じ問題を抱えていましたが、いくつかの掘削後にビルドが完了するまでに6分以上かかっていましたノードの再利用障害が見つかりました

0
Ala'a Hamad