デバッグ ランタイムのインストーラーの再配布がないため、できません (実際、ソフトウェア ライセンスでは配布が禁止されているため、何かをまとめたとしても EULA に違反することになります)。ただし、「デバッグ ビルド」には通常、4 つの個別のオプションが含まれ、他の 3 つはアプリの配布には影響しません。
シンボリック デバッグを可能にする .pdb ファイル (cl /Zi および link /DEBUG) を生成します。/OPT:ref をリンカー オプションに追加することをお勧めします。リンカーは、.pdb ファイルを作成しない場合、参照されていない関数を削除しますが、/DEBUG モードでは、明示的に追加しない限り、(デバッグ シンボルがそれらを参照するため) それらをすべて保持します。
私は通常、すべてのビルドでこれを行います。/OPT:ref を使用してリンカーの最適化をオンに戻す限り、実際にはコストはかかりません。また、クラッシュ ダンプを読みたくなった場合に、シンボルがあると便利です。
C ランタイム ライブラリのデバッグ バージョンを使用します (おそらく MSVCR*D.dll ですが、使用しているランタイムによって異なります)。これは、/MT または /MTd (または、dll ランタイムを使用していない場合は他の何か) に要約されます。
これは、もう再配布できないことを意味します。また、一部の libraty 関数のパフォーマンス、特にメモリ割り当てに大きな影響を与えます。デバッグ ランタイム バージョンは、初期化されていないデータのバグを明確にするために、接触するメモリを値で「汚染」するように注意しています。MSVCP* STL 実装では、デバッグ バージョンも通常行われるすべての割り当てプーリングを省略しているため、リーク チェッカーはサブ割り当てされている大きなメモリ チャンクではなく、ユーザーが考えているブロックを正確に表示できると思います。しかし、それは、malloc の呼び出しが多くなる上に、はるかに遅くなることを意味します。ポインターまたはイテレーター処理のバグがある場合、これは、発生する誤動作の種類に影響を与える可能性があります。
コンパイラの最適化をオフにします (/Od)。
これは多くのことを行います(この質問には、主題についての良い議論があります)が、基本的にパフォーマンスが低下します。多くの。残念ながら、シングルステップをスムーズに動作させるには、これが必要です。
プリプロセッサを設定すると、DEBUG または NDEBUG が定義されます。
これはさまざまな方法で多くのライブラリに影響を与えますが、最も顕著なのは assert() およびその仲間をコンパイルまたは排除することです。
したがって、これらの選択肢の組み合わせを少なくしてビルドを作成することを検討してください。私はシンボル (/Zi とリンク /DEBUG) とアサート (/DDEBUG) を使用するビルドをよく使用しますが、最適化されています (/O1 または /O2 または使用するフラグ)。バックトレースをクリア (/Oy-) し、通常のランタイム ライブラリ (/MT) を使用します。これは私のリリース ビルドに近いパフォーマンスを発揮し、ある程度デバッグ可能です (バックトレースは問題なく、シングル ステップはソース レベルでは少し奇抜ですが、アセンブリ レベルはもちろん問題なく動作します)。必要な数の構成を持つことができます。リリース 1 のクローンを作成し、デバッグの有用な部分をオンにするだけです。
アプリを再配布しようとすることに影響を与える唯一のものは 2.
別のマシンでデバッグしようとしている場合は、msvsmonにも興味があるかもしれません。