.pdbファイルを生成するリリース、なぜですか？

.pdbリリースでコンパイルするときにVisual Studio 2005がファイルを生成するのはなぜですか？私はリリースビルドをデバッグしないので、なぜ生成されるのですか？

PDBファイルがないと、アドレスレベルのデバッグ以外の方法で「リリース」ビルドをデバッグすることができないためです。最適化は実際にコードで数値を計算するため、問題が発生した場合（たとえば、例外がスローされた場合）に原因を特定することが非常に困難になります。生成されたアセンブリコードとソースコードの行を1対1で（または同じ順序で）一致させることができないため、ブレークポイントを設定することも非常に困難です。PDBファイルは、ユーザーとデバッガーを助け、事後デバッグを大幅に容易にします。

あなたのソフトウェアがリリースの準備ができていれば、それまでにすべてのデバッグを行うべきだったということをあなたは主張します。それは確かに真実ですが、覚えておくべき重要な点がいくつかあります。

1. "リリース"ビルドを使用して、アプリケーションをリリースする前にテストおよびデバッグする必要もあります。これは、最適化をオンにすると（「デバッグ」構成ではデフォルトで無効になっている）、他の方法ではキャッチできないような微妙なバグが発生する場合があるためです。このデバッグを行うときは、PDBシンボルが必要になります。

2. お客様は、「理想的な」条件下でのみ発生するエッジケースやバグを頻繁に報告します。これらは、ユーザーのマシンの奇抜な構成に依存しているため、ラボで再現することはほとんど不可能です。彼らが特に役立つ顧客であれば、スローされた例外を報告し、スタックトレースを提供します。または、リモートでソフトウェアをデバッグするためにマシンを借りることもできます。どちらの場合も、PDBファイルが役立ちます。

3. プロファイリングは常に、最適化を有効にした「リリース」ビルドで行う必要があります。また、PDBファイルは、プロファイルを作成するアセンブリ命令を、実際に記述したソースコードにマップして戻すことができるため、重宝します。

コンパイル後に PDBファイルに戻って生成することはできません。^*ビルド中にそれらを作成しないと、機会を失っています。それらを作成するために何も害はありません。それらを配布したくない場合は、バイナリから除外することができます。しかし、後でそれらを使用することを決定した場合、あなたは運が悪いです。必要な場合に備えて、常にそれらを生成してコピーをアーカイブすることをお勧めします。

本当にそれらをオフにしたい場合は、それは常にオプションです。プロジェクトの[プロパティ]ウィンドウで、変更する構成の[デバッグ情報]オプションを[なし]に設定します。

ただし、「デバッグ」と「リリース」の構成では、デフォルトでデバッグ情報の出力に異なる設定が使用されることに注意してください。この設定を保持する必要があります。デバッグビルドでは、「デバッグ情報」オプションが「フル」に設定されています。つまり、PDBファイルに加えて、デバッグシンボル情報がアセンブリに埋め込まれています。エディット・アンド・コンティニューなどのクールな機能をサポートするシンボルも入手できます。リリースモードでは、 "pdb-only"オプションが選択されています。これは、サウンドのように、アセンブリの内容に影響を与えずにPDBファイルのみを含みます。したがって、/binディレクトリにPDBファイルが存在するかどうかだけでは、それほど単純ではありません。ただし、「pdb-only」オプションを使用すると仮定すると、PDBファイル '

_{^*として、マルク・シャーマンは、コメントで指摘している限り、あなたのソースコードが変更されていない（あるいはあなたがバージョン管理システムから、元のコードを取得することができます）として、あなたはそれを再構築して、一致するPDBファイルを生成することができ、。少なくとも、通常は。これはほとんどの場合うまく機能しますが、コンパイラーが同じコードをコンパイルするたびに同じバイナリーを生成することは保証されていないため、微妙な違いがある場合があります。さらに悪いことに、その間にツールチェーンをアップグレードした場合（Visual Studioのサービスパックの適用など）、PDBが一致する可能性はさらに低くなります。事後の信頼できる世代を保証するPDBファイルの場合、バージョン管理システムのソースコードだけでなく、ビルドツールチェーン全体のバイナリもアーカイブして、ビルド環境の構成を正確に再作成できるようにする必要があります。言うまでもなく、PDBファイルを作成してアーカイブする方がはるかに簡単です。}

PDBはRelease、およびに対して生成できますDebug。これは次のように設定されます（VS2010ではVS2005でも同様にする必要があります）：

プロジェクト→プロパティ→ビルド→詳細設定→デバッグ情報

に変更してくださいNone。

.pdbファイルがないと、実稼働コードをステップ実行することは事実上不可能です。コストと時間がかかる他のツールに依存する必要があります。たとえば、トレースやwindbgを使用できることを理解していますが、それは実際に達成したいことに依存しています。特定のシナリオでは、本番データを使用してリモートコード（エラーや例外なし）をステップスルーして特定の動作を観察するだけで、.pdbファイルが役立ちます。それらなしでそのコードでデバッガーを実行することは不可能です。

リリースビルドをデバッグしないのはなぜですか。ときどき（まれに起こりますが、起こります）何らかの理由（異なるタイミング、小さな異なる動作など）でデバッグバージョンで再現できない顧客からの欠陥レポートを受け取ることがあります。その問題がリリースビルドで再現可能であると思われる場合は、対応するpdbを用意してください。

また、クラッシュダンプを利用してソフトウェアをデバッグすることもできます。顧客はそれをあなたに送信し、それを使用してソースの正確なバージョンを識別できます-Visual Studioは、クラッシュダンプを使用してデバッグシンボル（および正しく設定されている場合はソース）の適切なセットをプルします。シンボルストアに関する Microsoftのドキュメントを参照してください。

.PDBファイルは、「プログラムデータベース」の短い名前です。デバッガーのデバッグポイントと使用または参照されるリソースに関する情報が含まれています。デバッグモードでビルドしたときに生成されます。実行時にアプリケーションがデバッグできるようにします。

サイズは、デバッグモードでの.PDBファイルの増加です。アプリケーションをテストするときに使用されます。

pdbファイルの良い記事。

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

マルチプロジェクトソリューションでは、通常、PDBまたはXMLファイルをまったく生成しない1つの構成が必要です。Debug Infoすべてのプロジェクトのプロパティをに変更する代わりnoneに、特定の構成でのみ機能するビルド後のイベントを追加する方が便利だと思いました。

残念ながら、Visual Studioでは、構成ごとに異なるビルド後のイベントを指定することはできません。そこでcsproj、スタートアッププロジェクトのファイルを編集し、次のコードを（既存のPostBuildEventタグの代わりに）追加することで、これを手動で行うことにしました。

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

残念ながら、これによりビルド後のイベントテキストボックスが空白になり、そこに何かを入れると予測できない結果が生じる可能性があります。

デバッグシンボル（.pdb）およびXML doc（ .xml）ファイルは、合計サイズの大部分を占めており、通常の展開パッケージの一部ではありません。ただし、必要な場合にアクセスできるようにする必要があります。

1つの可能なアプローチ：TFSビルドプロセスの最後に、それらを別のアーティファクトに移動します。

実際、PDBファイルとシンボリック情報がないと、正常なクラッシュレポート（メモリダンプファイル）を作成できず、Microsoftは問題の原因を完全に把握できません。

PDBを使用すると、クラッシュレポートが改善されます。