以前、StackOverflowでこれについて話し合ったスレッドを見ましたが、もう一度見つけることができません。
System.Diagnostics.Contractクラスを「実際のコード」、つまり本番コードのリリースビルドで使用する必要があるかどうかを知りたいのですが。名前空間の説明に基づくと、コントラクトはデバッグまたは分析を目的としているように見えるため、これをお願いします。
機能の前後の条件が重要であり、if / then / elseチェックをたくさん書く手間を省くことができる便利なライブラリのようです。その場合、コアライブラリに代替手段はありますか？
ドキュメントのセクション5.1（引数の検証とコントラクト）では、コントラクトを使用するために検討する可能性のある3つの主な使用モードについて詳しく説明しています。
したがって、少なくとも公式ドキュメントに関する限り、リリースビルドでコントラクトを使用する使用モードが少なくとも1つあります。
引用：
独自のコードでコントラクトの使用を開始する前に、引数の検証に使用するコントラクトフォームと場所に影響を与えるいくつかの決定を行う必要があります（図2を参照）。作成する管理対象アセンブリごとに（プロジェクトごとに）、これらの決定を個別に行うことができることに注意してください。
コントラクトツールの最も簡単な使用法は、リリースビルド（使用法1）で実行時に引数の検証を実行する必要がないと判断した場合です。その場合、開発中にコントラクトツールを使用しますが、出荷されたビットでは使用しません。コントラクトリファレンスアセンブリをリリースビットと一緒に出荷できるため、クライアントは、呼び出しサイトのチェックを介して、デバッグビルドでパラメータ検証のランタイムチェックを取得できます。
リリースビルドで引数の検証が必要な場合の2番目に簡単なアプローチは、すべてのビルドでコントラクトチェックをオンにすることです（使用法2）。したがって、ツールを利用して、条件のランタイム文字列を生成し、コントラクトの継承を実行します。パラメータ検証用に特定の例外を生成するか、デフォルトのContractExceptionを使用するかを選択できます。リリースビルドでコントラクトツールを使用するリスクは、本番品質レベルに達していないツールに依存することです。
最も難しい組み合わせは、リリースビルドで引数の検証が必要な場合ですが、デバッグビルドでのみランタイムチェックにコントラクトツールを使用しており、リリースビルドでは使用していません（使用法3）。その場合、引数の検証をすでに行っている方法で、つまりif-then-throwステートメントを使用して記述し続ける必要があります（これらをlegacy-requiresと呼びます）。これらをツールで検出できるようにする場合は、それらの後に他のコントラクト（Ensuresなど）を追加するか、他のコントラクトが存在しない場合はContract.EndContractBlock（）を使用します。リリースビルドではランタイムチェックツールを使用していないため、コントラクトを継承することはなく、オーバーライドとインターフェイスの実装でレガシー要件を手動で繰り返す必要があることに注意してください。インターフェイスおよび抽象メソッドの場合、
これはまた、フレームワークの他の部分のみを使用する代替案が何であるかを示唆しています。if-then-throwを使用する通常の方法。