在我的 Web 项目中使用代码契约将如何影响部署？
如果应用程序中使用了代码合约，那么我们需要安装任何东西吗（来自代码合同包）在生产服务器上，例如将程序集放入 GAC 或在生产服务器上运行代码合同安装包？
或者只是将库放在 bin 文件夹中就可以了？
If code contracts are used in an application then do we need to install anything (from Code Contracts package) on production server like putting assemblies into GAC or running code contracts installation package on production server?
Or just putting libraries in bin folder will work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将它们放在 bin/ 文件夹中就足够了。
几周前做了类似的事情，我下载了图表引擎的试用版，将 .dll 放入我的 lib 文件夹中，并在我的网络项目中添加了对它们的引用。
当我们部署网站时，我们过去常常使用 Visual Studio 中的“发布”选项，这样我们就可以上传一个漂亮、干净的构建（现在我们有一个构建服务器）。
这一切都运行得很好，直到我们决定购买该组件，我安装了它，并将我们移动/安装的所有组件添加到 GAC。 我获取了程序集并将它们放入我们的 lib 文件夹中并重新添加了引用。
一切都工作正常，直到我们决定使用新的图表引擎程序集发布项目更新。 该网站停止工作了！ :(
经过短暂的调试，我们发现错误是图表引擎的新 .dll 没有输出到 bin 文件夹，因为它们位于 GAC 中。但是当我们发布到服务器时，它们却没有输出到 bin 文件夹中。不在那里，所以为了解决这个问题，我们只是将它们复制过来，一切又恢复正常了。
It should be enough to put them in the bin/ folder.
Did something like this a few weeks ago, i'd downloaded a trial for a charting engine, put the .dlls in my lib folder and added a reference to them in my web-project.
We used to use the "Publish" option in Visual Studio when we deployed a website so we got a nice, clean build to upload (now we have a build-server).
This all worked perfectly until we decided to buy the component, I installed it, and added all the assemblies we're moved/installed to the GAC. I took the assemblies and put them in our lib folder and re-added the references.
Everything we're working fine until we decided to publish an update to the project with the new chart-engine assemblies. The site stopped working! :(
After a short time of debugging we found that the error was the new .dlls for the chart-engines weren't outputed to the bin folder since they were in the GAC. But when we published to our server they're aren't there, so to fix the problem we just copied them over and everything worked like a charm again.
从您问题中链接的代码合同网站：
如果我错了，请纠正我，但我认为代码契约只是作为开发时的辅助而设计的。 因此，假设您在编译用于部署/生产的程序集时将禁用它们。
From the Code Contracts site linked in your question:
Correct me if I'm wrong, but I think that code contracts are designed as a development-time aid only. Therefore, it is supposed that you will disable them when you compile the asemblies intended for deployment/production.
我意识到这是一个较旧的线程，但问题仍然是一个有效的问题...
假设使用 .NET 4.0，System.Diagnostics.Contract 类已包含在 mscorlib.dll 中。 因此，您只需在任何地方安装 .NET 4.0 运行时即可。
您只需将 CodeContracts 包安装到开发计算机和将二进制文件编译为 IL 的任何其他计算机（即通过 VisualStudio、使用 csc.exe 的 msbuild - C# 编译器等）。 该安装包中包含多个 .exe 文件。 其中之一是“ccrewrite.exe”。 这是一个 IL 重写器，它在编译器完成后将 IL 代码注入到程序集中。 请注意，ccrewrite 和您使用的任何语言的 .NET 编译器不相关、连接或共享任何依赖项。
编译二进制文件后，无需在将执行代码的任何服务器上安装或部署任何内容。 无论您在项目设置中配置的选项如何：
仅当您需要将合约公开给解决方案之外的库/API 并且为该项目启用静态检查时，才会使用 CodeContract 参考程序集 您也不应该直接引用它们，也不需要任何类型的构建后步骤将它们复制到任何 bin 文件夹中（除了我刚刚提到的将它们暴露给另一个库/API 的情况）。
华泰
I realize this is an older thread but the question is still a valid one...
Assuming the use of .NET 4.0, the System.Diagnostics.Contract classes are already included in mscorlib.dll. So all you'll need to have installed anywhere is the .NET 4.0 runtime.
You'll only need to have the CodeContracts package installed to the dev machines and any other machines that compile your binaries down to IL (i.e. via VisualStudio, msbuild using csc.exe - the C# compiler, etc.). There is are several .exes included in that install package. One of them is 'ccrewrite.exe'. This is an IL rewriter that injects IL code into your assemblies after the compiler has completed. Note that ccrewrite and the .NET compiler you use for whatever language you are using are not related, connected, or share any dependencies.
Once your binaries are compiled, there is no need to install or deploy anything to any of the servers where your code will execute. This is true regardless of the options you have configured in your Project Settings:
The CodeContract Reference Assemblies are only used when you need to expose your contracts to a Library/API that is outside of your Solution and Static Checking is enabled for that project. You also should not directly reference them nor do you need any kind of post-build step to copy them into any bin folder (except in the case I just mentioned about exposing them to another Library/API).
HTH