署名済みアセンブリの読み込みが遅いのはなぜですか?
-
06-07-2019 - |
質問
今週説明できない奇妙な問題に遭遇しました:サードパーティアセンブリ(Xceed Gridと他のコンポーネントの一部)の署名バージョンを使用するようにアプリケーションを切り替え、アプリケーションの開始時間がトイレに入りました。アプリケーションが署名済みアセンブリをロードするたびに、ロードに30秒かかりました。アプリケーションの開始は5秒から90秒を超えました。ここで何が起こっているのでしょうか?!
その他の情報:
- これは、.NET 3.5 SP1で実行されるWinFormsアプリです。
- コンピューターにインターネット接続がありませんでした(意図的に、セキュリティのために)。
解決
これらのリンクをご覧ください:
- http://blogs.technet.com/markrussinovich/ archive / 2009/05/26 / 3244913.aspx
- http: //blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx
彼らは助けになるかもしれません。システムの構成は、.NETフレームワークがアセンブリを検証するために多くの余分な作業を行っていることを意味している可能性があります。この場合は、あまりうるさくないように設定できます。
他のヒント
Jason Evansの投稿には回答が含まれていますが、リンクの形式です。ここに実際の解決策を投稿するのが良いと思いました:
実行可能ファイルと同じフォルダーにAppname.exe.configファイルを作成します(Appnameは実行可能ファイルの名前です。開発の場合、これはデバッグ出力フォルダーにあります)。これは、メインの設定ファイルに他のエントリがないことを前提とするxmlファイルを示しています。ファイルが既にある場合は、必要に応じて新しいセクション/テキストを追加するだけだと思います:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
</configuration>
他の誰かがこの投稿に出くわした場合に備えて、私はこのページを見つけて見つけようとしていたので、問題をもう少し追跡しました。
マシン上にある既存のCRLがタイムアウトになり、まだ新しいCRLで更新されていない場合、プロセスを実行するたびにCRLがチェックされるようです。これをテストするには、 http://crl.microsoft.com/でCRLにアクセスします。 pki / crl / products / CodeSignPCA.crl で有効期限を確認してください。次に、IE内で機能しないプロキシを構成します。有効期限を過ぎてマシンの日付を設定し、アプリケーションを再テストします。
NICが無効になっている場合、CRLはチェックされません。
NICにゲートウェイがない場合、CRLはチェックされません。
プロキシを有効にしてゲートウェイを使用している場合、CRLがチェックされ、プロキシに問題がある場合、このタイムアウトが発生します。
インターネットに正常に接続すると、CRLが更新され、当面は問題ありません。
私のアプリケーションは.NET 2.0の古いXceedコンポーネントを使用しており、永久に機能しているため、何が起こっているのかを理解するのに時間がかかりました。
5秒から90秒に渡りますか??アセンブリの作成者に連絡し、署名のみを変更したかどうかを尋ねる必要があると思います:-)
アセンブリの証明書が検証されるようにセキュリティ設定が設定されていると思います。そのため、Webにアクセスして証明書を検証し、タイムアウトを待機する可能性があります(30秒は非常に一般的なタイムアウト値です)。
その30秒で何が起こるかを見ると、これを確認できます。私の推測が真実であるためには、これらの90秒間でCPU使用とHDDアクセスがほとんどないはずです。 CPUの使用率が高い場合、またはHDDに縛られている場合は、別のものです。
ところで:別のオプションは、HDDが完全にいっぱいで、アセンブリが極端に断片化されている場合です(ただし、その場合に聞いたのは90秒以上です)。
「ステップオーバー」でVisual Studioからアプリケーションを起動してみてください。これにより、各アプリをステップオーバーすることでコードが開始されるため、時間がかかるものを確認できます。私はかつてこれを持っていましたが、私のSQLサーバーは本当に台無しになったことが判明しました。
時間がかかる理由を調べる別の方法は、ロード中のコードに散らばったブレークポイントを配置し、ボトルネックを確認することです。アプリケーションが最初にあなたののように前に90秒かかる場合は、おそらくXCeedを使用しているか、署名済みのアセンブリを読み込みます。
ところで、アプリケーションをプロファイリングするより良い方法があることを知っていますが、この迅速で汚い方法は、このような問題をデバッグするのに非常に素晴らしく効率的です
署名されたアセンブリはNGENされていないかもしれませんが、署名されていないアセンブリはNGENされていません。