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.
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.
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 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:
- cccheck is the tool that runs post-build and is a static checker that verifies contracts at compile-time
- ccrewrite is the tool that runs post cccheck, rewriting the IL and generating the runtime checking from the contracts
(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.
Fody is an extensible tool for weaving .net assemblies based on a plugin architecture.
