哪些工具执行 IL 的编译后修改？
最近提到 PostSharp 让我想起了这一点：
去年我工作时，我们正在考虑使用 PostSharp 将检测注入到我们的代码中。 这是在 Team Foundation Server 团队构建/持续集成环境中。
考虑到这一点，我对 PostSharp 的运行方式有一种挥之不去的感觉——它编辑编译器生成的 IL。 这让我有点困扰。
我不太担心 PostSharp 无法正确完成其工作； 我很担心这是我第一次听说这样的工具。 我担心其他工具可能不会考虑到这一点。
事实上，随着我们的进展，我们确实遇到了一些问题，因为 PostSharp 对原始 IL 所在的文件夹感到困惑。这破坏了我们的构建。 这似乎是由于与解析项目引用的 MSBUILD 目标发生冲突。 冲突似乎是由于 PostSharp 使用临时目录来存储 IL 的未修改版本所致。
无论如何，我当时没有 StackOverflow 可以参考！ 现在我知道了，我想问一下大家是否知道还有其他工具可以在构建过程中编辑 IL； 或者 Microsoft 是否在 Visual Studio、MSBUILD、Team Build 等中考虑了此类工具。
更新：感谢您的回答。
底线似乎是，至少对于 VS 2010，微软确实应该意识到这种事情可能会发生。 所以如果VS2010在这方面出现问题，那么微软可能要承担责任。
A recent mention of PostSharp reminded me of this:
Last year where I worked, we were thinking of using PostSharp to inject instrumentation into our code. This was in a Team Foundation Server Team Build / Continuous Integration environment.
Thinking about it, I got a nagging feeling about the way PostSharp operates - it edits the IL that is generated by the compilers. This bothered me a bit.
I wasn't so much concerned that PostSharp would not do its job correctly; I was worried about the fact that this was the first time I could recall hearing about a tool like this. I was concerned that other tools might not take this into account.
Indeed, as we moved along, we did have some problems stemming from the fact that PostSharp was getting confused about which folder the original IL was in. This was breaking our builds. It appeared to be due to a conflict with the MSBUILD target that resolves project references. The conflict appeared to be due to the fact that PostSharp uses a temp directory to store the unmodified versions of the IL.
At any rate, I didn't have StackOverflow to refer to back then! Now that I do, I'd like to ask you all if you know of any other tools that edit IL as part of a build process; or whether Microsoft takes that sort of tool into account in Visual Studio, MSBUILD, Team Build, etc.
Update: Thanks for the answers.
The bottom line seems to be that, at least with VS 2010, Microsoft really should be aware that this sort of thing can happen. So if there are problems in this area in VS2010, then Microsoft may share the blame.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我知道 Mono.Cecil，一个扩展 System.Reflection 工具集的框架库，它由 < a href="http://www.codeproject.com/KB/cs/LinFuPart1.aspx" rel="nofollow noreferrer">林Fu 项目。
我不确定构建过程支持，您应该检查它们的大小。
I know about Mono.Cecil, a framework library expanding the System.Reflection toolset, it's used by the LinFu project.
I'm not sure about build process support, you should check them out for size.
.NET 4.0 包含来自 Microsoft Research 的代码契约项目，该项目执行运行时（以及一些编译时）对方法的前置/后置条件的断言。 断言在库中实现，.NET 编译器将前置/后置条件作为 IL 中的方法调用发出。 然而，由于合同通常是在方法开始时指定的，因此辅助工具需要重写 IL，以将断言放在正确的顺序和正确的位置。
编辑：
（我找不到有关这些工具的任何其他技术信息）
我还没有使用过 Visual Studio 2010，但我看过代码合同功能的演示，它集成到 IDE 构建过程中。 cccheck 必须始终运行，如果构建的程序集中存在合约，则返回代码。 如果它们存在，则代码将表示 ccrewrite 应该运行。
.NET 4.0 includes the code contracts project from Microsoft Research, which performs runtime (and some compile-time) assertions on the pre/post conditions of your methods. The assertions are implemented in a library, and a .NET compiler emits the pre/post conditions as methods calls in the IL. However, since the contracts are generally specified at the start of a method, a secondary tool needs to rewrite the IL to put the assertions in the correct order and correct locations.
EDIT:
(I can not find any additional technical information about these tools)
I have not yet used Visual Studio 2010, but I've seen a demo of the Code Contracts feature and it is integrated into the IDE build process. cccheck must always run, returning a code if contracts are present in the built assembly. If they are present, the code would signify that ccrewrite should run.
我确实知道 Dotfuscator（一种代码混淆器）确实修改了程序集程序集的 IL，并且在许多构建过程中使用它。
IL 的修改不仅是为了代码混淆和保护，还为了向您的应用程序注入附加功能（请参阅我们 (PreEmptive) 的有关运行时智能的博客文章 此处。
此外，Microsoft 的通用编译器基础结构能够读取程序集、修改它们并重写它们。请参阅 CodePlex 项目。
I do know that Dotfuscator, a code obfuscator, does modify the IL of assemblies assemblies and it is used in many build processes.
The IL is modified not only for code obfuscation and protection but also to inject additional functionality into your applications (see our (PreEmptive's) blog posts on Runtime Intelligence here.
In addition Microsoft's Common Compiler Infrastructure has the ability to read in assemblies, modify them and rewrite them. See CodePlex for the project.
Fody 是一个可扩展工具，用于基于插件架构编织 .net 程序集。
Fody is an extensible tool for weaving .net assemblies based on a plugin architecture.