最终目标是为驻留在我无法控制的外部程序集中的类指定契约（即我不能直接向该类添加契约）。
到目前为止我已经尝试过：
ContractClassFor属性。
不起作用，因为目标类必须指向合约类。
通过对自动生成的程序集进行逆向工程，手动构建合同引用程序集（即 MyAsm.Contracts.dll）。
不起作用，因为在我编译它之后，重写器就会启动并方便地剥离ContractDeclarativeAssembly属性，这使得工具无法将程序集识别为“合同引用程序集”。我找不到关闭重写器的方法。
创建一个与目标程序集具有相同名称、版本、强名称（如果有）和其他属性的“假”程序集，并在其中放置具有相同名称方法的同名类。然后在打开“构建契约引用”选项的情况下编译该程序集，然后获取生成的契约引用程序集并使用它。
由于某种原因，这也不起作用，尽管我不知道到底是什么原因。静态检查器只是忽略我的 smartypants 生成的参考程序集，就好像它不存在一样。
还有一件事，以防万一：目标程序集是为 .NET 2.0 编译的，我无法为 4.0 重新编译它。
Update
编写一个具有定义契约的“包装”库是毫无疑问的。
其一，需要编写大量额外代码。但即使您将其放在一边，这也可能是一个重大的性能损失：我必须（可能）为每个用作“遗留”方法的返回类型的“遗留”类型创建包装器类。但即便如此，故事还没有结束。想象一下，某些方法可能返回对基接口的引用，然后调用代码可能会将它们转换为派生接口，以查看该对象是否支持更多功能。我该如何包裹它们？我可能必须提供定制Cast<T>()我的包装类上的方法，它将尝试强制转换底层类/接口，并在成功时返回结果的包装器。最后，我的整个代码库将变得如此复杂，以至于可能不值得。
另一方面，CC 团队本身已经成功解决了这个问题：他们确实为 mscorlib、System.Core 和其他一些系统程序集提供了正确的合同引用程序集，不是吗？他们是如何建造它们的？如果他们能做到，那么我看不出有什么理由我不能完成同样的把戏。
哦，好吧，实际上，我确实看到了一个原因：我不知道该怎么做。 :-) – Fyodor Soikin 18 秒前编辑
您可能已经快完成 (2) 了。请务必关闭您手动构建的 C# 程序集的契约重写。关闭所有运行时检查和静态分析，重写器不应启动。将其放在所有其他 CodeContracts 程序集所在的位置，例如对于 /bin/X.dll，创建一个转到 /bin/CodeContracts/X.Contracts.dll 的程序集。
See http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/5fe7ad4e-d4f1-4bb5-806e-a1e31f550181 http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/5fe7ad4e-d4f1-4bb5-806e-a1e31f550181。你是对的——只需通过查看 Reflector 创建所有正确的位即可。我想这样做是为了将契约添加到我的 F# 程序集中，直到 F# 可以处理契约。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
