Hi, thanks for sharing this issue.
I don't have any firsthand experience with DelegateDecompiler, but based on what you've described, it looks as though this tool is making use of an IL-analysis step, either inside the build process for your project or possibly at run time.
NCrunch collects its code coverage and performance data from your code by instrumenting it at build time. Basically, it picks up the .DLL after the compiler has built it, and adds a whole range of additional IL instructions that enable it to track the way your code behaves under execution. The injected IL is designed as much as possible not to change the behaviour of your code in any way, but it does still physically change the code. I don't doubt that the DelegateDecompiler tool is picking up NCrunch's instrumentation and not making sense of it.
There isn't really any way for NCrunch to internally handle a situation like this, as it has no power over tools that disassemble instrumented code. There are two ways you can work around this problem:
1. Suppress NCrunch's instrumentation for the decompiled methods using
code coverage suppression comments. This will allow you to select targeted areas of your code that you don't want to have instrumented, so that they don't interefere with DelegateDecompiler.
2. Turn off NCrunch's instrumentation for the projects involved using the
instrument output assembly project-level configuration setting.
Note that both of the above workarounds will result in the loss of code coverage data collected by NCrunch.