问题标签 [code-contracts]

我刚刚开始使用 .NET 的代码合同，我有一个像这样的保护条款

并将其替换为

我不确定这是否正确，因为合同将处理 I/O 问题，但不确定这是否是一个问题。

基本上问题是：使用合同来确保 I/O 问题（或外部/非单元问题）有什么问题吗？

I've recently migrated a lot of manual precondition testing and exception throwing with code contracts. Instead of upgrading to .NET 4, I've been using the Microsoft.Contracts.dll assembly so I could stick to .NET 3.5 a bit longer (this is a library that is used both by .NET 3.5 and .NET 4 assemblies). I've set up the contracts rewriter in Visual Studio 2010 and the contracts work just fine.

However, since I've done that switch, I've noticed that the debugger acts funny in methods with contracts, especially in classes with a ContractInvariantMethod. The execution cursor doesn't seem to always match the highlighted line, some breakpoints fail to be hit and I've had a method in which the debugger couldn't tell the local variable names and would show stuff like CS$1$0000. This is in debug builds.

Are there known issues about using the code contracts in Microsoft.Contracts.dll in .NET 3.5 through VS10? Do similar issues arise with the code contracts in .NET 4?

[Edit] This question lead me to create a bug on 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 接口添加新合同。从另一个合同类继承一个合同类似乎是重用该代码的可能方式。但是我收到以下错误：

这是代码合同的限制还是我做错了？我们的项目中有很多接口继承，如果我不知道如何解决这个问题，这感觉就像代码合同的交易破坏者。

我最近听了 Kevin Hazzard 在 .Net Rocks show 570 ( http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/ )中谈论代码合同。他提到启用运行时合同检查作为一些人可能会选择使用而其他人可能不会选择使用的选项。

为什么不对代码合同使用运行时合同检查？对性能有显着的负面影响吗？其他原因？

如果禁用此功能，如何在运行时处理方法中的先决条件？

我对单元测试有相当多的了解。我一直在尝试阅读有关代码合同的信息。它真的有助于单元测试吗？它是否被高估了，尤其是当我们谈论代码合同有助于进行单元测试时。我特指.net 4.0 中的合同。我使用 nunit 进行单元测试。

考虑这种不可变类型：

这里需要注意两点：

• 有一个契约不变量，它确保Path财产永远不会null
• 构造函数检查path参数值以尊重先前的合同不变量

在这一点上，一个Setting实例永远不能有一个null Path属性。

现在，看看这种类型：

基本上，它有自己的合同不变量（_path现场），在静态检查期间无法满足（参见上面的评论）。这对我来说听起来有点奇怪，因为它很容易证明：

• settings是不可变的
• settings.Path不能为空（因为 Settings 有对应的契约不变量）
• 所以通过分配settings.Path给_path，_path不能为空

我在这里错过了什么吗？

我想知道在 ASP.NET MVC 2 中使用“代码合同”属性作为验证规则的可用选项。

我有以下情况：

在第1行并打开静态检查器，我会收到一条警告，说它_somethingElse可能为空，如果我添加合同，它会给我错误

[Type] 实现接口方法 {Interface.Method} 因此不能添加要求

在这里做的最好的事情是什么？我看到的选项包括

1. 一个保护条款，虽然它看起来有点极端
2. 一种Contract.Assume
3. 我没有想到的隐藏的第三个选项

请注意，该字段readonly在构造函数中设置值后无法更改。因此，来自代码合同的警告似乎有点无关紧要。

当我在我的 WPF 控制项目上启用代码协定时，我遇到了一个在编译时创建的自动生成文件 (XamlNamespace.GeneratedInternalTypeHelper) 的问题。请注意，生成的文件称为 GeneratedInternalTypeHelper.g.cs，它与 GeneratedInternalTypeHelper.gics 不同，后者有几篇过时的博客文章。

我不完全确定它的目的是什么，但我假设某些内部反射对解决 XAML 很重要。问题是它没有代码合约，代码合约系统也不够智能，无法将其识别为自动生成的文件。这会导致静态检查器出现一堆错误。

我尝试寻找解决此问题的方法，但似乎没有人在开发 WPF 控件并使用代码协定。我确实遇到了一个有趣的属性 ContractVerificationAttribute，它采用布尔值来设置是否要验证程序集或类。这允许您将类装饰为未验证。遗憾的是，每次编译都会重新生成 GeneratedInternalTypeHelper，因此无法仅排除这一类。然而，相反的情况是可能的，将程序集装饰为未验证，然后选择加入每个类。

为了减轻明显的黑客攻击，我想创建一个测试，该测试至少可以验证公开的类是否具有代码契约验证，并使用如下测试来确保自己的类至少得到验证：

正如您所看到的，它获取控件程序集中的所有类，并从公司命名空间中找到不是自动生成的匿名类型（<>WeirdClassName）的类。

（我还需要排除资源和设置，但我希望你明白）。

我不喜欢这个解决方案，因为有一些方法可以避免合同验证，但目前这是我能想到的最好的方法。如果有人有更好的解决方案，请告诉我。

我一直在使用新的 System.Diagnostics.Contracts 类，因为它起初看起来非常有用。检查入站参数、返回值等的静态方法。它是一个干净的接口，可以替换许多 if-then 语句和内部构建的库工具。

但是，在大多数运行时情况下，它似乎没有多大用处。据我所知，它不会引发错误，所以我无法得知合同是否失败。它会弹出一个带有错误的对话框。如果我在一个很少有人看的远程机器上运行 wcf 服务……我怎么知道合同失败了？如果我不能捕捉到错误发生的事实，我怎么能让服务的调用者知道他们搞砸了？

Throw-Catch 已经存在了一段时间，我不明白为什么 Contracts 想要绕过它。我是否试图错误地使用这个东西？如果是这样，那么有人给了我一个运行时合约有意义的真实情况。肯