在Visual Studio 2010 Professional中使用代码合约（即没有静态检查）对于类库有多好主意？(How good idea is it to use code contracts

在Visual Studio 2010 Professional中使用代码合约（即没有静态检查）对于类库有多好主意？(How good idea is it to use code contracts in Visual Studio 2010 Professional (ie. no static checking) for class libraries?)

我创建了类库，其中一些被世界各地的其他用户使用，现在我开始使用Visual Studio 2010。我想知道对于我来说，转换到使用代码合同，而不是使用常规的旧版本库，风格的if语句。

即。 代替这个：

if (fileName == null) throw new ArgumentNullException("fileName");

用这个：

Contract.Requires(fileName != null);

我问的原因是我知道静态检查器不适用于我，所以我对编译器无法验证的一些假设感到有点紧张。 这可能会导致类库不能编译下载它的人，当他们有静态检查器时。 再加上我甚至不能重现问题的事实，会让它很难修复，而且我会认识到，如果它看起来甚至没有编译出我的课程库框。

所以我有几个问题：

如果您有权访问静态检查器，默认情况下是否启用？ 或者是否有需要在类库中打开的设置（因为我没有静态检查器，所以我不会） 我的担心没有根据吗？ 上述情况是一个真正的问题吗？

任何的建议都受欢迎。

---

编辑 ：让我澄清我的意思。

假设我在课堂上有以下方法：

public void LogToFile(string fileName, string message) { Contracts.Requires(fileName != null); // log to the file here }

然后我有这样的代码：

public void Log(string message) { var targetProvider = IoC.Resolve<IFileLogTargetProvider>(); var fileName = targetProvider.GetTargetFileName(); LogToFile(fileName, message); }

现在，IoC在这里开始解析一些“随机”类，它为我提供了一个文件名。 假设对于这个库来说，我不可能找到一个不会给我一个非空文件名的类，但是，由于IoC调用的性质，静态分析无法验证这一点，因此可能会认为可能的值可能为空。

因此，静态分析可能会得出结论： LogToFile方法有一个用null参数调用的风险，因此无法构建。

我知道我可以在代码中添加一些假设，并说编译器应该如此，因为从该方法返回的fileName永远不会为null，但如果我没有静态分析器（VS2010 Professional），则上面的代码会为我编译，因此我可能会将此作为适用于Ultimate的人找到的睡眠错误。 换句话说，没有编译时警告，说这里可能存在问题，所以我可能会按原样释放库。

那么这是一个真实的场景和问题吗？

I create class libraries, some which are used by others around the world, and now that I'm starting to use Visual Studio 2010 I'm wondering how good idea it is for me to switch to using code contracts, instead of regular old-style if-statements.

ie. instead of this:

if (fileName == null) throw new ArgumentNullException("fileName");

use this:

Contract.Requires(fileName != null);

The reason I'm asking is that I know that the static checker is not available to me, so I'm a bit nervous about some assumptions that I make, that the compiler cannot verify. This might lead to the class library not compiling for someone that downloads it, when they have the static checker. This, coupled with the fact that I cannot even reproduce the problem, would make it tiresome to fix, and I would gather that it doesn't speak volumes to the quality of my class library if it seemingly doesn't even compile out of the box.

So I have a few questions:

Is the static checker on by default if you have access to it? Or is there a setting I need to switch on in the class library (and since I don't have the static checker, I won't) Are my fears unwarranted? Is the above scenario a real problem?

Any advice would be welcome.

---

Edit: Let me clarify what I mean.

Let's say I have the following method in a class:

public void LogToFile(string fileName, string message) { Contracts.Requires(fileName != null); // log to the file here }

and then I have this code:

public void Log(string message) { var targetProvider = IoC.Resolve<IFileLogTargetProvider>(); var fileName = targetProvider.GetTargetFileName(); LogToFile(fileName, message); }

Now, here, IoC kicks in, resolves some "random" class, that provides me with a filename. Let's say that for this library, there is no possible way that I can get back a class that won't give me a non-null filename, however, due to the nature of the IoC call, the static analysis is unable to verify this, and thus might assume that a possible value could be null.

Hence, the static analysis might conclude that there is a risk of the LogToFile method being called with a null argument, and thus fail to build.

I understand that I can add assumptions to the code, saying that the compiler should take it as given that the fileName I get back from that method will never be null, but if I don't have the static analyzer (VS2010 Professional), the above code would compile for me, and thus I might leave this as a sleeping bug for someone with Ultimate to find. In other words, there would be no compile-time warning that there might be a problem here, so I might release the library as-is.

So is this a real scenario and problem?

最满意答案

当您的LogToFile和Log方法都是库的一部分时，一旦打开静态检查器，您的Log方法就可能无法编译。 当你向其他人提供的代码使用静态检查器编译你的代码时，这当然也会发生。 但是，据我所知，你的客户端的静态检查器不会验证你发布的程序集的内部。 它会根据程序集的公共API静态检查自己的代码。 所以只要你只是运送DLL，你会没事的。

当然，对于实际启用静态检查程序的用户而言，装运库存在一个非常烦人的API的改变，因此，如果您测试了API的可用性，我认为仅向您的库提供合同定义是明智的无论是否有静态检查器。

请注意将现有的if (cond) throw ex调用更改为Contracts.Requires(cond)调用您已经在先前发行版中发布的公共API调用的请求。 请注意， Requires方法会抛出一个不同的异常（如果我正确记得，则为RequiresViolationException ），而不是您通常会抛出的异常（一个ArgumentException ）。 在这种情况下，请使用Contract.Requires重载。 这样你的API接口保持不变。

When both your LogToFile and Log methods are part of your library, it is possible that your Log method will not compile, once you turn on the static checker. This of course will also happen when you supply code to others that compile your code using the static checker. However, as far as I know, your client's static checker will not validate the internals of the assembly you ship. It will statically check their own code against the public API of your assembly. So as long as you just ship the DLL, you'd be okay.

Of course there is a change of shipping a library that has a very annoying API for users that actually have the static checker enabled, so I think it is advisable to only ship your library with the contract definitions, if you tested the usability of the API both with and without the static checker.

Please be warned about changing the existing if (cond) throw ex calls to Contracts.Requires(cond) calls for public API calls that you have already shipped in a previous release. Note that the Requires method throws a different exception (a RequiresViolationException if I recall correctly) than what you'd normally throw (a ArgumentException). In that situation, use the Contract.Requires overload. This way your API interface stays unchanged.