web-dev-qa-db-ja.com

デバッグ情報を「full」または「pdb-only」としてリリースビルドをコンパイルする必要がありますか？

C＃プロジェクトのVisual Studio 2010では、[プロジェクトのプロパティ]> [ビルド]> [詳細]> [デバッグ情報]に移動すると、3つのオプション（なし、完全、またはpdbのみ）があります。 この質問 への答えに基づいて、fullとpdbのみの違いのいくつかを理解していると思います。ただし、リリースビルドにはどちらが適切ですか？ 「フル」を使用すると、パフォーマンスに影響がありますか？ 「pdb-only」を使用すると、実稼働の問題をデバッグするのが難しくなりますか？

「full」と「pdbonly」の違いは何ですか？ https://docs.Microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

c#visual-studiodebuggingbuilddebug-symbols
109
RationalGeek

pdb-onlyでビルドします。リリースされた製品にデバッガをアタッチすることはできませんが、クラッシュダンプを取得する場合は、Visual Studioまたは WinDBG を使用して、クラッシュ時のスタックトレースとメモリダンプを調べることができます。

pdb-onlyではなくfullを使用すると、実行可能ファイルをデバッガーに直接アタッチできることを除いて、同じ利点が得られます。製品と顧客を考慮して、これが妥当かどうかを判断する必要があります。

クラッシュレポートが入ったときに参照できるように、PDBファイルを必ずどこかに保存してください。デバッグシンボルを保存するために symbol server を設定できる場合は、はるかに優れています。

noneを使用してビルドすることを選択した場合、フィールドでクラッシュしたときに頼ることはできません。クラッシュの事後調査を行うことはできません。これにより、問題を追跡する能力が著しく妨げられる可能性があります。

パフォーマンスに関する注意：

John Robbins と Eric Lippert の両方が/debugフラグに関するブログ投稿を書いており、両方ともこの設定がzeroパフォーマンスへの影響。コンパイラが最適化を実行する必要があるかどうかを指示する別個の/optimizeフラグがあります。

87
Matt Dillard

[〜＃〜] warning [〜＃〜]MSDN ドキュメント for/debugスイッチ（Visual Studioではデバッグ情報）古くなっているようです！これはincorrectであるものです

/ debug：fullを使用する場合、JIT最適化コードの速度とサイズに多少の影響があり、コード品質にわずかな影響があることに注意してください。/debug：full。リリースコードの生成には、/ debug：pdbonlyまたはPDBなしをお勧めします。

/ debug：pdbonlyと/ debug：fullの1つの違いは/ debug：fullを使用すると、コンパイラはDebuggableAttributeを出力します。これは、デバッグ情報が利用可能であることをJITコンパイラに伝えるために使用されます。

それでは、今何が本当ですか？

  1. Pdb-only– .NET 2.0より前は、リリースされた製品（顧客のマシン）からのクラッシュダンプの調査に役立ちました。しかし、デバッガーを接続できませんでした。これは、.NET 2.0の場合ではありません。 exactlyFullと同じです。
  2. Full–これはクラッシュダンプの調査に役立ち、デバッガーをリリースビルドにアタッチすることもできます。ただし、MSDNの言及とは異なり、パフォーマンスには影響しません（.NET 2.0以降）。 Pdb-onlyとまったく同じです。

それらがまったく同じ場合、なぜこれらのオプションがあるのですか？ John Robbins（windows debugging god） 発見 これらは歴史的な理由で存在します。

.NET 1.0には違いがありましたが、.NET 2.0には違いがありません。 .NET 4.0は同じパターンに従うようです。 CLRデバッグチームで再確認した後、まったく違いはありません。

JITterがデバッグビルドを行うかどうかを制御するのは、/ optimizeスイッチです。 <…>

一番下の行は、ソースコードでデバッグできるように、/ optimize +および/ debugスイッチを使用してリリースビルドをビルドすることです。

それから彼はそれを証明し続けます。

現在、最適化は個別のスイッチ/optimize（Visual StudioではOptimize code）。

要するに、DebugInfoの設定がpdbのみまたはfullに関係なく、同じ結果が得られます。推奨されるのは、Noneを避けることです。リリースされた製品のクラッシュダンプを分析したり、デバッガをアタッチしたりすることができないためです。

56
rpattabi

PDBのみが必要になりますが、PDBファイルをユーザーに提供する必要はありません。ただし、バイナリと一緒に使用すると、WinDbgなどのデバッガにクラッシュダンプをロードして、プログラムが実際に失敗した場所を確認できます。これは、アクセスできないマシンでコードがクラッシュする場合にかなり役立ちます。

完全デバッグでは、[Debuggable]属性がコードに追加されます。これは速度に大きな影響を与えます。たとえば、一部のループ最適化は、シングルステップ実行を容易にするために無効にされる場合があります。さらに、追跡をオンにするため、JITプロセスに小さな影響があります。

16
blowdart

未処理の例外ハンドラを作成中です。pdbのみを使用すると、スタックトレースに行番号が含まれます。それ以外の場合は、なしを選択するとSub/Functionの名前が取得されます。

.pdbを配布しないと、pdbのみのビルドでもスタックトレースに行番号が表示されません。

だから、私は私のVB app。

4
rheitzman