微软代码合同框架有多成熟?

微软最近在DevLabs上发布了一个商业授权的代码合同框架。 我们有兴趣在我们的项目(主要是C#,一些C ++ / CLI)中使用它们来逐步replace所有的自定义validation代码,但是我很想知道其他人在使用它之前的经验,特别:

  • 你认为这个框架对于大型复杂的商业项目是否足够成熟?

  • 你在使用时遇到了什么问题?

  • 你从中得到什么好处?

  • 目前比现在更痛苦吗?

我意识到,这是一个有点主观的问题,因为它需要意见,但是鉴于这个框架是.NET 4.0的一个非常重要的部分,并且将(可能)改变我们所有编写validation代码的方式,所以我希望这个问题将会被留下打开收集这方面的经验,以帮助我作出一个具体的,可回答的问题的决定:

我们是否应该在下个月开始使用它?

请注意,我们不提供代码API,只有一个Web服务,所以对于大多数代码打破兼容性而言,抛出的exceptiontypes并不是一个问题。 然而,正如我希望更多的人,而不仅仅是我会受益于这个职位和答案,围绕这个领域的任何细节都是值得欢迎的。

最后一个成熟的回应是在2009年,而.NET 4已经不在了。 我想我们应该有一个更新:

代码合同对于您的Debug版本可能已经足够成熟了。

我意识到这是从“无害”到“无害”的升级。

代码合同主页链接到相当全面的PDF格式的文件。 文档概述了第5节中的使用指南。总结一下, 您可以select在发布版本中重新编写IL的合同工具有多勇敢

我们正在使用“不要重写我的发行IL”模式。

到目前为止,我最享受这个意想不到的好处:代码less了,代码也就less了 。 你所有的守卫条款都融化了。

if(arg != null) { throw new ArgumentNullException("arg"); } // Blank line here insisted upon by StyleCop 

变为:

 Contract.Requires(arg != null); 

你的function更短。 你的意图更清晰。 而且,您不必再写一个名为ArgumentShouldNotBeNull的testing,只是为了达到100%的覆盖率。

到目前为止,我遇到了两个问题:

  • 我有一个依靠合同失败成功的unit testing。 你可能会认为testing的存在是一个错误,但是我想以testing的formslogging这个特定的禁止。 testing在我的构build服务器上失败,因为我没有安装工具。 解决scheme:安装工具。

  • 我们使用了两个重写IL的工具: Code Contracts和PostSharp 。 他们相处得不好。 PostSharp的2.0.8.1283解决了这个问题。 尽pipe如此,我会谨慎地评估任何两个IL重写工具的相处程度。

到目前为止,这些好处远远超过了危害。

解决其他答案中提出的过时问题:

  • 代码合同的文件是相当彻底的,但遗憾的是在PDF中。
  • 至less有一个由Microsoft托pipe的代码合同论坛 。
  • 代码合同标准版是免费的,如果你有任何VS2010许可证。
  • .NET 4出来了。 我在实现generics集合接口时碰到了微软的合同。

我一直在使用代码合同来进行一些小而复杂的独立项目,这个项目需要inheritance一些BCL类并使用其他类。

当你在一个完全隔离的环境中工作时,合同事情看起来很棒,只是你自己的代码和原始types,但是一旦你开始使用BCL类(直到.NET 4.0没有自己的合约),validation者不能检查他们是否会违反任何要求/确保/不variables,因此您会收到很多关于潜在的不满意限制的警告。

另一方面,它确实发现了一些可能是真正的缺陷的无效或潜在不满意的约束。 但是很难find这些,因为噪音太大,很难找出哪些可以修复。 通过使用假设机制,可以抑制BCL类的警告,但是这有点自欺欺人,因为这些类将来会有合同,假设会降低它们的价值。

所以我现在的感觉是,因为在3.5版本中,我们试图build立一个validation者没有充分理解的框架,可能值得等待4.0。

从这个线程来看,我认为它还不够成熟,不足以用于企业级项目。 我自己并没有使用它,但是人们仍然遇到一些会让你的合同关键项目停下来的错误。 这看起来像是一个非常棒的框架,他们提供的示例video令人兴奋,但我会等待:

  • 存在一个社区论坛。 您将希望能够讨论与其他开发人员遇到的不可避免的问题,并且希望知道有一个相当强大的开发人员基础来讨论解决scheme。
  • 一个成功的试点项目发布。 一般来说,当微软研究院发布了一些他们认为已经足够成熟的商业项目中使用的东西时,他们将与一个组织一起试点,然后将这个项目公开发布,以作为概念validation和试火的所有主要特点。 这将使人们充满信心,大多数常见的合同scheme都被涵盖和运作。
  • 更完整的文档。 简单而简单,在某些时候,你会想要使用微软代码合同来做一些你还不能做的合同。 您希望能够快速明确地推断您的scheme尚未得到支持。 目前的文档会让你猜测和尝试不同的东西,但在我看来,这将导致大量的浪费时间。

这还不够成熟。

一旦微软发布了它的价格合理的版本,但没有静态代码分析,它将不会被使用。

VS的版本已经非常昂贵,只有less数人能买得起。

这是一个耻辱微软杀死这个惊人的想法与他们的定价政策。 我希望代码合同将成为主stream,但他们不会。

史诗失败。