問題タブ [code-contracts]

.NET で Code Contracts を使い始めたばかりで、このようなガード句がありました

そしてそれを

コントラクトは I/O の問題に対処するため、これが正しいかどうかはわかりませんが、これが問題かどうかはわかりません。

基本的な質問は次のとおりです。コントラクトを使用して I/O の懸念 (または外部/非ユニットの懸念) を確実にすることに問題はありますか?

私は最近、コード コントラクトを使用して、多くの手動の前提条件テストと例外スローを移行しました。.NET 4 にアップグレードする代わりに、Microsoft.Contracts.dllアセンブリを使用していたので、.NET 3.5 をもう少し使い続けることができました (これは、.NET 3.5 アセンブリと .NET 4 アセンブリの両方で使用されるライブラリです)。Visual Studio 2010 でコントラクト リライターをセットアップしましたが、コントラクトは問題なく動作します。

ただし、その切り替えを行ってから、コントラクトを使用するメソッド、特に ContractInvariantMethod を使用するクラスで、デバッガーの動作がおかしくなることに気付きました。実行カーソルが強調表示された行と常に一致するとは限らず、一部のブレークポイントがヒットしないため、デバッガーがローカル変数名を認識できず、CS$1$0000. これはデバッグ ビルドにあります。

Microsoft.Contracts.dllVS10 から .NET 3.5でのコード コントラクトの使用に関する既知の問題はありますか? .NET 4 のコード コントラクトでも同様の問題が発生しますか?

[編集] この質問により、Microsoft Connect でバグを作成することになりました: https://connect.microsoft.com/VisualStudio/feedback/details/573983/code-contract-rewriting-messes-up-local-variable-names-in -iterator-methods-while-debugging

私は MS Code Contracts を使用していますが、インターフェイスの継承と ContractClassFor 属性を使用する際に問題が発生しました。

これらのインターフェイスとコントラクト クラスが与えられた場合:

IOne と ITwo は実質的なインターフェイスと言えます。したがって、IOneContract には、必要なチェックのために大量のコードが含まれます。

そのすべてを IOne インターフェイスの ITWoContract で複製したくありません。ITwo インターフェイスの新しいコントラクトを追加したいだけです。あるコントラクト クラスを別のコントラクト クラスから継承することは、そのコードを再利用する可能性が高い方法のようです。それでも、次のエラーが表示されます。

これは Code Contracts の制限ですか、それとも間違っていますか? 私たちのプロジェクトには多くのインターフェース継承があり、この問題を回避する方法がわからない場合、これは Code Contracts の契約違反のように感じます。

最近、.Net Rocks show 570（ http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/ ）でのコードコントラクトに関するKevinHazzardの話を聞きました。彼は、実行時の契約チェックを有効にすることを、一部の人が使用することを選択する可能性がある一方で、他の人は使用しない可能性があるオプションとして言及しています。

コードコントラクトにランタイムコントラクトチェックを使用しないのはなぜですか？パフォーマンスに重大な悪影響はありますか？その他の理由？

この機能を無効にした場合、実行時にメソッドの前提条件をどのように処理しますか？

単体テストについてかなりの知識があります。コード契約について読み込もうとしています。それは本当に単体テストに役立ちますか? 特にユニットテストを行うのに役立つコードコントラクトについて話すとき、それは過大評価されていますか? 私は特に .net 4.0 のコントラクトについて言及しています。単体テストにはnunitを使用しています。

この不変のタイプを考えてみましょう。

ここで注意すべき2つのこと：

• Pathプロパティが決してすることができないことを保証する契約不変量がありますnull
• pathコンストラクターは、引数の値をチェックして、前のコントラクト不変条件を尊重します

この時点で、Settingインスタンスがnull Pathプロパティを持つことはできません。

ここで、このタイプを見てください。

_path基本的に、静的チェック中に満たすことができない独自のコントラクト不変量（フィールド上）があります（上記のコメントを参照）。それを証明するのは簡単なので、それは私には少し奇妙に聞こえます：

• settings不変です
• settings.Pathnullにすることはできません（設定には対応するコントラクトが不変であるため）
• したがって、に割り当てることによりsettings.Path、_pathnullに_pathすることはできません

私はここで何かを逃しましたか？

ASP.NET MVC 2 の検証規則として「コード コントラクト」属性を使用するための利用可能なオプションを知りたいです。

次のシナリオがあります。

1行目で静的チェッカーをオンにすると、それが null である可能性があるという警告が表示されます。_somethingElseコントラクトを追加すると、エラーが発生します。

[Type] インターフェイス メソッド {Interface.Method} を実装しているため、require を追加できません

ここで何をするのが最善ですか？私が見るオプションは次のとおりです

1. 少し極端に見えますが、ガード条項
2. aContract.Assume
3. 私が考えもしなかった隠された第3の選択肢

readonlyこのフィールドは、コンストラクターで値を設定した後は変更できないことに注意してください。したがって、コード コントラクトからの警告は少し無関係に思えます。

WPF コントロール プロジェクトでコード コントラクトを有効にすると、コンパイル時に作成された自動生成ファイル (XamlNamespace.GeneratedInternalTypeHelper) で問題が発生しました。生成されたファイルは GeneratedInternalTypeHelper.g.cs と呼ばれ、古いブログ投稿がいくつかある GeneratedInternalTypeHelper.gics と同じではないことに注意してください。

その目的が正確にはわかりませんが、内部リフレクションが XAML を解決することが重要であると想定しています。問題は、コード コントラクトがないことと、コード コントラクト システムが自動生成ファイルとして認識できるほどスマートでないことです。これにより、静的チェッカーから一連のエラーが発生します。

この問題の解決策を探してみましたが、誰も WPF コントロールを開発してコード コントラクトを使用していないようです。アセンブリまたはクラスを検証するかどうかを設定するブール値を取る、興味深い属性である ContractVerificationAttribute を見つけました。これにより、クラスを検証されていないものとして装飾できます。残念ながら、GeneratedInternalTypeHelper はコンパイルごとに再生成されるため、この 1 つのクラスだけを除外することはできません。ただし、逆のシナリオも可能です。アセンブリを検証されていないものとして装飾し、すべてのクラスをオプトインします。

明らかなハッキングを軽減するために、公開されたクラスにコード コントラクトの検証があることを少なくとも検証するテストを作成したいと考えました。次のようなテストを使用して、独自のクラスが少なくとも検証されていることを確認します。

ご覧のとおり、コントロール アセンブリ内のすべてのクラスを取得し、自動生成された匿名型 (<>WeirdClassName) でもない会社の名前空間からクラスを見つけます。

(リソースと設定も除外する必要がありますが、理解していただければ幸いです)。

契約の検証を回避する方法があるため、私はこの解決策が好きではありませんが、現在のところ、私が思いつくことができる最善の方法です. 誰かがより良い解決策を持っている場合は、私に知らせてください。

最初は非常に便利に思えたので、新しいSystem.Diagnostics.Contractsクラスで遊んでいます。インバウンド引数や戻り値などをチェックする静的メソッド。これはクリーンなインターフェイスであり、多くのif-thenステートメントや内部で構築されたライブラリツールを置き換えることができました。

ただし、ほとんどの実行時の状況ではあまり役に立たないようです。私の知る限り、エラーは発生しないので、契約が失敗したかどうかを知ることはできません。エラーのあるダイアログボックスが表示されます。人間がほとんど見ないリモートボックスでwcfサービスを実行している場合、契約が失敗したことをどのようにして知ることができますか？エラーが発生したという事実をトラップできない場合、サービスの呼び出し元に、彼らが失敗したことをどのように知らせることができますか？

Throw-Catchはしばらく前から存在していますが、コントラクトがこれをバイパスしたい理由がわかりません。私はこれを間違って使用しようとしていますか？もしそうなら、誰かが私にランタイムコントラクトが理にかなっている現実の状況を教えてくれます。ケン