.pdbリリースでコンパイルするときにVisualStudio2005がファイルを生成するのはなぜですか？リリースビルドをデバッグしないのに、なぜそれらが生成されるのですか？
127997 次
9 に答える
454
PDBファイルがないと、アドレスレベルのデバッグ以外の方法で「リリース」ビルドをデバッグすることはできません。最適化は実際にコードに影響を与えるため、問題が発生した場合（たとえば、例外がスローされた場合）に原因を見つけるのは非常に困難です。ソースコードの行を生成されたアセンブリコードと1対1で（または同じ順序で）一致させることができないため、ブレークポイントを設定することさえ非常に困難です。PDBファイルは、ユーザーとデバッガーを支援し、事後デバッグを大幅に容易にします。
ソフトウェアをリリースする準備ができていれば、それまでにすべてのデバッグを行う必要があるということを強調します。それは確かに真実ですが、覚えておくべき重要なポイントがいくつかあります。
また、「リリース」ビルドを使用して（リリースする前に）アプリケーションをテストおよびデバッグする必要があります。これは、最適化をオンにすると（「デバッグ」構成ではデフォルトで無効になっている）、他の方法では検出できない微妙なバグが表示される場合があるためです。このデバッグを行うときは、PDBシンボルが必要になります。
お客様は、「理想的な」条件下でのみ発生するエッジケースやバグを頻繁に報告します。これらは、そのユーザーのマシンの奇抜な構成に依存しているため、ラボで再現することはほとんど不可能です。彼らが特に役立つ顧客である場合、彼らはスローされた例外を報告し、スタックトレースを提供します。または、マシンを借りてソフトウェアをリモートでデバッグすることもできます。どちらの場合でも、PDBファイルが役に立ちます。
プロファイリングは、最適化が有効になっている「リリース」ビルドで常に実行する必要があります。また、PDBファイルは、プロファイリングされるアセンブリ命令を実際に作成したソースコードにマップして戻すことができるため便利です。
コンパイル後に戻ってPDBファイルを生成することはできません。*ビルド中に作成しないと、機会を失ってしまいます。それらを作成することは何も害はありません。それらを配布したくない場合は、単にバイナリからそれらを省略することができます。しかし、後でそれらが必要だと判断した場合は、運が悪いことになります。必要になった場合に備えて、常にそれらを生成してコピーをアーカイブすることをお勧めします。
本当にそれらをオフにしたい場合は、それは常にオプションです。プロジェクトの[プロパティ]ウィンドウで、変更する構成の[デバッグ情報]オプションを[なし]に設定します。
ただし、「デバッグ」構成と「リリース」構成では、デフォルトでデバッグ情報を出力するために異なる設定が使用されることに注意してください。この設定を維持する必要があります。デバッグビルドの場合、[デバッグ情報]オプションは[完全]に設定されます。これは、PDBファイルに加えて、デバッグシンボル情報がアセンブリに埋め込まれていることを意味します。また、編集と続行などの優れた機能をサポートする記号も表示されます。リリースモードでは、「pdb-only」オプションが選択されています。これは、アセンブリの内容に影響を与えることなく、PDBファイルのみを含みます。/binしたがって、ディレクトリ内のPDBファイルの単なる存在または不在ほど単純ではありません。ただし、「pdb-only」オプションを使用すると仮定すると、PDBファイルは
* Marc Shermanがコメントで指摘しているように、ソースコードが変更されていない限り（またはバージョン管理システムから元のコードを取得できる限り）、それを再構築して一致するPDBファイルを生成できます。少なくとも、通常は。これはほとんどの場合うまく機能しますが、同じコードをコンパイルするたびにコンパイラが同じバイナリを生成することは保証されていないため、微妙な違いがある場合があります。さらに悪いことに、その間にツールチェーンにアップグレードを行った場合（Visual Studioにサービスパックを適用する場合など）、PDBが一致する可能性はさらに低くなります。事後の信頼できる生成を保証するためPDBファイルの場合、ビルド環境の構成を正確に再作成できるように、バージョン管理システムのソースコードだけでなく、ビルドツールチェーン全体のバイナリもアーカイブする必要があります。言うまでもなく、PDBファイルを簡単に作成してアーカイブする方がはるかに簡単です。
于 2011-03-28T09:48:10.633 に答える
98
ReleasePDBは、に対しても生成することもできますDebug。これは次のように設定されます（VS2010では、VS2005では類似している必要があります）：
プロジェクト→プロパティ→ビルド→詳細→デバッグ情報
に変更するだけNoneです。
于 2011-03-28T09:37:57.417 に答える
8
.pdbファイルがないと、製品コードをステップ実行することは事実上不可能です。費用と時間がかかる可能性のある他のツールに依存する必要があります。たとえば、トレースやwindbgを使用できることは理解していますが、実際には何を達成したいかによって異なります。特定のシナリオでは、本番データを使用してリモートコード（エラーや例外なし）をステップ実行し、特定の動作を観察する必要があります。これは、.pdbファイルが役立つ場合です。それらがなければ、そのコードでデバッガーを実行することは不可能です。
于 2012-11-29T11:18:55.927 に答える
7
リリースビルドをデバッグしないのはなぜですか？場合によっては（まれにしか発生しませんが）、何らかの理由（タイミングの違い、動作の違いなど）でデバッグバージョンで再現できない欠陥レポートを顧客から受け取ることがあります。その問題がリリースビルドで再現可能であると思われる場合は、一致するpdbがあれば問題ありません。
于 2011-03-28T09:41:37.150 に答える
4
また、クラッシュダンプを利用してソフトウェアをデバッグすることもできます。顧客がそれを送信すると、それを使用してソースの正確なバージョンを識別できます。VisualStudioは、クラッシュダンプを使用して、適切なデバッグシンボルのセット（および正しく設定されている場合はソース）をプルします。シンボルストアに関するMicrosoftのドキュメントを参照してください。
于 2015-01-19T23:01:15.203 に答える
2
.PDBファイルは「プログラムデータベース」の略称です。デバッガーのデバッグポイントと、使用または参照されるリソースに関する情報が含まれています。デバッグモードとしてビルドすると生成されます。アプリケーションが実行時にデバッグできるようにします。
サイズは、デバッグモードでの.PDBファイルの増加です。これは、アプリケーションをテストするときに使用されます。
pdbファイルの良い記事。
http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P
于 2014-05-23T05:34:05.823 に答える
1
マルチプロジェクトソリューションでは、通常、PDBまたはXMLファイルをまったく生成しない1つの構成が必要です。Debug Infoすべてのプロジェクトのプロパティをに変更する代わりにnone、特定の構成でのみ機能するビルド後のイベントを追加する方が便利だと思いました。
残念ながら、Visual Studioでは、構成ごとに異なるビルド後のイベントを指定することはできません。csprojそこで、スタートアッププロジェクトのファイルを編集し、（既存のPostBuildEventタグの代わりに）以下を追加して、これを手動で行うことにしました。
<PropertyGroup Condition="'$(Configuration)' == 'Publish'">
<PostBuildEvent>
del *.pdb
del *.xml
</PostBuildEvent>
</PropertyGroup>
残念ながら、これによりビルド後のイベントテキストボックスが空白になり、そこに何かを入れると予測できない結果になる可能性があります。
于 2015-12-29T21:36:48.520 に答える
0
デバッグシンボル（.pdb）およびXMLドキュメント（ .xml）ファイルは、合計サイズの大部分を占めるため、通常の展開パッケージの一部であってはなりません。ただし、必要に応じてアクセスできるようにする必要があります。
考えられるアプローチの1つは、TFSビルドプロセスの最後に、それらを別のアーティファクトに移動することです。
于 2017-11-07T13:11:23.280 に答える
-1
実際には、PDBファイルとシンボリック情報がないと、クラッシュレポート（メモリダンプファイル）を正常に作成することは不可能であり、Microsoftは問題の原因を完全に把握することはできません。
そのため、PDBを使用すると、クラッシュレポートが改善されます。
于 2019-05-08T20:45:56.420 に答える