Visual Studioのデバッグとリリースの違いは何ですか？

.NETでのデバッグVisual Studioリリースの重複の可能性

Visual Studioのデバッグとリリースの違いは何ですか？

最も重要なことは、デバッグモードでは最適化が行われず、リリースモードでは最適化が行われることです。コンパイラは非常に高度であり、コードをかなりトリッキーな低レベルで改善できるため、これは重要です。その結果、コードの一部の行がまったく命令なしで残されたり、すべてが混同されたりする場合があります。段階的なデバッグは不可能です。また、ローカル変数は不思議な方法で最適化されることが多いため、変数が「最適化されて」しまうため、ウォッチとクイックウォッチは機能しないことがよくあります。また、他にも多数の最適化があります。最適化された.NETコードをデバッグしてみてください。

もう1つの重要な違いは、このため、デフォルトのリリース設定では、広範なデバッグシンボル情報を生成する必要がないことです。これは、お気づきかもしれない.PDBファイルであり、これにより、デバッガーは、どのアセンブリー命令がどのコード行に対応するかなどを把握できます。

「デバッグ」と「リリース」は、実際には、ビルドとデバッグに影響を与える可能性があるさまざまな設定の2つのラベルにすぎません。

「デバッグ」モードでは、通常、次のようになります。

• プログラムデバッグデータベースファイル。これにより、実行時にソース内でプログラムの実行を非常に厳密に追跡できます。
• すべての最適化がオフになりました。これにより、変数の値を検査し、他の方法で最適化またはインライン化された可能性のある関数にトレースできます。
• リリースと比較してデバッグモードで異なる動作をするコードを記述できる_DEBUGプリプロセッサ定義。たとえば、デバッグ中にのみ使用する必要があるASSERTを計測します。
• デバッグオプションをオンにしてコンパイルされたライブラリへのリンク。これは通常、実際の顧客には展開されません（サイズとセキュリティ上の理由から）。

「リリース」モードでは、最適化がオンになり（複数のオプションが使用可能です）、_ DEBUGプリプロセッサー定義が定義されていません。ただし、通常はPDBファイルを生成する必要があります。これは、物事がより高速に実行されているときにリリースモードで「デバッグ」できると非常に便利だからです。

ほとんどの場合、デバッグには、デバッグ時に役立つ多くの追加情報が含まれています。リリースモードでは、これはすべてカットされ、パフォーマンスと交換されます。

プロジェクトのコンパイルオプションを実行して比較すると、違いがわかります。

質問がネイティブ/ C ++コードに関するものであると仮定します（この表現から完全に明確ではありません）。

基本的に、デバッグではすべてのコード生成の最適化がオフになっています。一部のライブラリ（STLなど）では、デフォルトでより厳密なエラーチェックが行われます（デバッグ反復子など）。より多くのデバッグ情報が生成されます（「編集して続行」など）。エラーをキャッチするためにより多くのものがコードで生成されます（ローカル変数の値は初期化されていないパターンに設定され、デバッグヒープが使用されます）。

また、明らかに、デバッグモードでは、デバッグに役立つ追加のスレッドが多数作成されます。これらは、デバッガーを接続するかどうかに関係なく、プロセスの存続期間を通じてアクティブなままです。私の関連の質問を参照してくださいここに。

ビルドフラグを使用すると、ロギングと「コンソール」メッセージングを変更するためだけに使用する必要のあるさまざまなロジックが可能になることは明らかですが、悪用され、低レベルだけでなく実際のビジネスロジックを劇的に変更する可能性があります。

たとえばMFCを使用する場合、デバッグプロジェクトは再配布不可能なDLLバージョンとMFC90D.DLLリンクしますが、リリースビルドはなどの再配布可能なバージョンとリンクしますMFC90.DLL。これはおそらく他のフレームワークに似ています。

したがって、おそらく開発用でないマシンでデバッグビルドアプリケーションを実行することはできません。

既存のリリースビルド構成からコピーしたアプリケーションを開発したときも、この質問に興味を持ちました。

そのアプリケーションをデバッグモードで使用することに興味のある開発者がいるため、Release構成からコピーされたReleaseMyBuildという名前のこのビルド構成を作成するのに何が必要かを考えました（したがって、最適化をリリースするためのすべての設定が必要です） ）混乱するビルド構成名にもかかわらず、チームを突然変更してデバッグビルドにする。

私は、プロジェクトの構成が名前であり、Joris Timmermansが言及する「設定全体」を選択するための便利な方法であると考えました。最適化されたリリースビルドとして「FOO」という名前のビルド構成を作成する設定がどのようなものであるかについての要点を知りたかったのです。

ここにその一例を示します。Visual Studio 2010の空のプロジェクトテンプレートから新しいVCXPROJを作成しました。次に、それをコピーして両方を編集しました。1つ目はデバッグコンテンツを保持し、2つ目はリリースコンテンツを保持します。ここに、関連する違いを中心とした差分があります...

リリース

<PropertyGroup>
    <WholeProgramOptimization>true</WholeProgramOptimization>

<ClCompile>
    <Optimization>MaxSpeed</Optimization>
    <FunctionLevelLinking>true</FunctionLevelLinking>
    <IntrinsicFunctions>true</IntrinsicFunctions>
<Link>
    <EnableCOMDATFolding>true</EnableCOMDATFolding>
    <OptimizeReferences>true</OptimizeReferences>

デバッグ

<PropertyGroup>
    <UseDebugLibraries>true</UseDebugLibraries>`

<ClCompile>
    <Optimization>Disabled</Optimization>

興味深いのは、リンクセクションで両方がGenerateDebugInformationtrueに設定されていることです。

明らかな違いは、バイナリのサイズです。デバッグビルドは、リリースビルドよりも大きなバイナリを生成します。

Debugでコンパイルすると、シンボルテーブルがコードファイルのコンパイル済みオブジェクトに追加され、デバッグプログラムがこれらのバイナリを利用してオブジェクトや変数の値にアクセスできるようになります。

もう1つの観察可能な違いは、リリースモードでは、デバッグモードではバイナリが致命的なエラーでクラッシュするだけです。VisualStudioでアプリケーションのデバッグを開始すると、エラーステートメントの正確な場所を示すコールスタックを確認できます。 。

実際には簡単に入手できる情報がないため、正確な違いが何であるかはわかりません。

しかし、主な違いは、リリースバージョンが結果のDLLファイルを破損することがあり、アプリケーション、Webアプリケーションが使用できなくなることです。

悲しいことに、デバッグビルドを本番環境に置く必要があります。そして、はい、公開するには古き良きFTPを使用する必要があります。