webdevqa.jp.net

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

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

241
m.edmondson

PDBファイルがないため、アドレスレベルのデバッグ以外では「リリース」ビルドをデバッグすることはできません。最適化は実際に多くのことを行います何かがうまくいかない場合(例外がスローされるなど)、犯人を見つけるのが非常に難しくなります。ソースコードの行を、生成されたアセンブリコードと1対1で(または同じ順序で)一致させることができないため、ブレークポイントを設定することさえ非常に困難です。 PDBファイルは、ユーザーとデバッガーを支援し、事後デバッグを大幅に簡単にします。

ソフトウェアのリリースの準備ができていれば、それまでにすべてのデバッグを完了しておくべきだと主張します。確かにそうですが、留意すべき重要な点がいくつかあります。

  1. 「リリース」ビルドを使用して、アプリケーションを(リリースする前に)またテストおよびデバッグする必要があります。これは、最適化を有効にすると(「デバッグ」設定ではデフォルトで無効になっている)、微妙なバグが発生することがあるためです。このデバッグを行うとき、PDBシンボルが必要になります。

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

  3. プロファイリングは、always最適化を有効にした「リリース」ビルドで行う必要があります。繰り返しになりますが、PDBファイルは便利です。プロファイルされているアセンブリ命令を、実際に書いたソースコードにマッピングし直すことができるからです。

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

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

ただし、「デバッグ」および「リリース」構成doは、デフォルトではデバッグ情報の出力に異なる設定を使用することに注意してください。この設定を保持する必要があります。デバッグビルドの[デバッグ情報]オプションは[フル]に設定されます。つまり、PDBファイルに加えて、デバッグシンボル情報がアセンブリに埋め込まれます。また、編集と継続などのクールな機能をサポートするシンボルも取得します。リリースモードでは、「pdbのみ」オプションが選択されます。これは、サウンドのように、PDBファイルのみを含み、アセンブリのコンテンツに影響を与えません。したがって、/binディレクトリにPDBファイルが存在するかしないかというほど単純ではありません。ただし、「pdb-only」オプションを使用すると、PDBファイルの存在はコードの実行時のパフォーマンスにまったく影響しません。

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

391
Cody Gray

PDBは、ReleaseおよびDebugに対して生成できます。これは(VS2010では設定されますが、VS2005では同様である必要があります):

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

それをNoneに変更するだけです。

81
Aliostad

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

8
user1714880

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

7
jdehaan

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

4
rlranft

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

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

Pdbファイルの良い記事。

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

2
Ajay2707

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

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

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

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

1
GregRos

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

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

0
Mark Johanes

実際、PDBファイルとシンボリック情報がなければ、正常なクラッシュレポート(メモリダンプファイル)を作成することは不可能であり、Microsoftは問題の原因を完全には把握していません。

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

0
prosti