何が問題になっているのかについてより多くの情報が必要な場合に、アプリケーションにデバッグコードを追加する良い方法は何ですか？
アプリケーションが期待どおりに動作しない場合（例外がスローされるなど）、通常は、アプリケーションの特定のポイントに多くのデバッグコードを挿入して、正確に何が行われているのか、より正確に概要を把握します。特定のオブジェクトの値は、このエラーがトリガーされた場所をよりよく追跡するためです。次に、問題が発生しているユーザーに新しいインストーラーを送信します。問題が再度発生した場合は、ログを見て、ユーザーの発言を確認します。
ただし、このデバッグコードをすべて本番コードに含めたくありません。これは、必ずしも適切ではない情報を含む非常に大きなデバッグファイルを作成するためです。
もう1つの問題は、コードベースが変更され、次回、同じデバッグコードがアプリケーションの別の部分に配置される可能性があることです。
質問
このデバッグコードを必要な場合にのみ本番コード内にマージし、アプリケーション内の正しいポイントに表示させる方法はありますか？
git mergeだけが必要になるように、gitのようなバージョン管理システムでそれを行うことはできますか？
追伸私が今話しているアプリケーションはC＃で書かれた.NETです。
VCS側の場合：
Gitの場合、クリーンバージョンとデバッグバージョンには2つの別々のブランチが必要です。通常の作業は、デバッグ情報が追加されたマスター、デバッグ-
debugブランチ（またはbugfixから分岐したdebugブランチ）で行われます。ライフサイクルの間、マスターから
debugへの変更を永久にマージします。したがって、デバッグ情報の量のみが異なる2つのバージョンがあります。バグハンティングの後、ブランチからの変更の関連部分のみ（debugからマスターに）バックマージします。
ちなみに、Mercurial with MQは分岐とマージの摩擦が少なく、メインラインブランチを1つだけ使用する一方で、デバッグコードの挿入を使用できます。
私見の最善の方法は、例外メッセージ内に必要なすべての情報を記録することによる防止です。理想的なケースでは、これは通常のログメッセージとともに-開発環境でバグを再現するのに十分です。しかし、理想的とは言えない場合でも、正確な根本原因を特定するために必要な追加のデバッグログが少なくて済むので、調査に集中できます。
後者の場合、他にも示唆されているように、ログメッセージレベルを慎重に設定し、本番環境で適切なログレベルしきい値を適用することにより、余分なログメッセージによって引き起こされる中断とパフォーマンスのペナルティを最小限に抑えることができます。私はC＃ロギングフレームワークに精通していませんが、Javaではすべての主流のロギングフレームワークがこれを許可しているため、.Netの世界でも同様のソリューションを見つけることができると確信しています。
ログのデバッグ（）、情報（）、トレース（）レベルで一連のメッセージを表示できます。 nlog のようなものはそれを可能にします。本番環境では、ログのレベルを設定でき、必要なものはすべて破棄されます。
編集：nlogを独自のクラスの下にラップし、そのクラスを使用することをお勧めします。このようにして、ロガーを変更する場合、変更する必要があるクラスは1つだけです。
log4net のようなロギングフレームワークを調べましたか（他にもありますが、これは.NETで最も人気があるようです）。私はJava=同等、Log4Jを使用しており、Info、Warn、Error、Debug、Fatalなどのさまざまなレベルでメッセージをログに記録する機能があります。アプリケーションのログレベルは、こうすることで、通常は「致命的」なログレベルでアプリケーションを運用環境で実行できますが、ワークステーションでは「警告」または「デバッグ」でロギングを実行すれば、再コンパイルは必要ありません。
唯一の難しい部分は、ログメッセージのレベルを把握することです。
デバッグコードが大きなデバッグファイルを作成することだけが心配な場合は、それを本番環境に置くことができますが、無効にすることができます（グローバルフラグを使用する場合があります）
したがって、ユーザーに有効にしたい場合は、設定ファイルを変更するか、実行可能ファイルに引数を渡してもらいます。
注：デバッグコードはすでにあると思いますが、そうでない場合は、サルダトリオンの answer が最適だと思います。
デバッグが組み込まれている製品バージョンと、組み込まれていない製品バージョンを使用しないことをお勧めします。デバッグを製品コードに組み込み、次のいずれかを行います。
- 上記のさまざまな提案から、起動時にオンまたはオフにする方法を選択します。
- オンデマンドでオンにします。
おそらく、プロパティグリッドとリフレクションを使用して、実行時にオブジェクトを検査し、秘密のホットキーによってアクティブ化することで、後者を実行できます。
大きなデバッグファイルを吐き出すのが心配な場合は、すべてをメモリに書き込み、必要に応じて（たとえば、ユーザーのコマンドで、例外で、またはその特定のスイッチがオンになっている場合にのみ）ファイルまたは画面に出力することができます。機能など...）
デバッグについての最後のスローは、多くの場合、物理的に読み取る必要があるデバッグファイルに書き込む代わりに、メソッドとプロパティ内で条件がtrueまたはfalseであるかどうかをアサートするだけで多くの時間を節約できることです。状態だった。