「フル」または「pdbのみ」のデバッグ情報を使用してリリースビルドをコンパイルする必要がありますか？

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

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

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

あなたが一緒に行く場合fullではなくpdb-only、あなたは実行ファイルがデバッガに直接取り付けることができることを除いて、同じ利益を得るでしょう。あなたの製品と顧客にとってこれが妥当かどうかを判断する必要があります。

クラッシュレポートが届いたときに参照できるように、PDBファイルをどこかに保存してください。これらのデバッグシンボルを格納するようにシンボルサーバーを設定できれば、はるかに便利です。

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

パフォーマンスに関するメモ：

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

警告 / debugスイッチに関する MSDN ドキュメント（Visual Studioではデバッグ情報です）は古くなっているようです！これは間違っているものです

あなたが/デバッグを使用する場合：フル：、JIT最適化されたコードとと/デバッグコードの品質上の小さな衝撃の速度とサイズに多少影響があることに注意してフル。リリースコードの生成には、/ debug：pdbonlyまたはno PDB をお勧めします。

/ debug：pdbonlyと/ debug：fullの違いの1つは、/ debug：fullを指定すると、コンパイラーがを発行DebuggableAttributeすることです。

では、今は何が正しいのでしょうか？

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

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

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

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

結論としては、/ optimize +と/ debugスイッチのいずれかを使用してリリースビルドをビルドし、ソースコードでデバッグできるようにする必要があります。

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

これで、最適化は別のスイッチの一部になります/optimize（Visual Studioではと呼ばれますOptimize code）。

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

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

完全デバッグでは、コードに[Debuggable]属性が追加されます。これは速度に大きな影響を与えます。たとえば、シングルステップを簡単にするために、一部のループ最適化が無効になっている場合があります。さらに、トラッキングがオンになるため、JITプロセスにわずかな影響があります。

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

.pdbを配布しない場合、pdbのみのビルドでも、スタックトレースの行番号を取得できません。

したがって、私はVBアプリからのexeファイルとともにpdbを配布（XCOPYをLANに配置）しています。