I am having a problem with a project not building in NCrunch. It seems to be similar to this post (http://forum.ncrunch.net/yaf_postsm4052_Issue-when-using-NCrunch-with-Code-Contracts-and-Fody.aspx#post4052), but it's an internally developed NuGet package, where I just implemented a generic class. When I try to implement this generic abstract class in one of my projects, I get the following Exception message below. This only happens in NCrunch. I even removed the generic class in our NuGet project and NCrunch was able to build the project as expected.

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
at _Mono.Collections.Generic.Collection`1..ctor(Int32 capacity)
at _Mono.Cecil.Cil.CodeReader.ReadCode()
at _Mono.Cecil.Cil.CodeReader.ReadFatMethod()
at _Mono.Cecil.Cil.CodeReader.ReadMethodBody()
at _Mono.Cecil.Cil.CodeReader.ReadMethodBody(MethodDefinition method)
at _Mono.Cecil.MethodDefinition.<>c.<get_Body>b__36_0(MethodDefinition method, MetadataReader reader)
at _Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
at _Mono.Cecil.MethodDefinition.get_Body()
at nCrunch.Reflection.Cecil.CecilMethod.get_HasBody()
at nCrunch.TestExecution.Frameworks.DefaultClassMethodDescriptionLocator.ExtractClassMemberDataFromType(ReflectedType type, Boolean hashAllMethods)
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.(ReflectedAssembly , IDictionary`2 , TestFrameworkDescription[] , Boolean )
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.ExtractClassMethodData(TestFrameworkDescription[] applicableTestFrameworks, IDictionary`2 codeFileIDsByFilePath, Boolean hashMethods)
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters , FilePath , BuildOutput , DirectoryPath[] , FilePath[] )
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters )

I'm trying to create a small sample to reproduce. Do you just need a sample of the project that is unable to build or would you need a sample of a NuGet package that also causes this issue?

My apologies for the severely delayed response. I had updated NCrunch and thought that corrected the issue I was seeing, but it turns out that I just hadn't implemented the inheritance. After several attempts, I was able to reproduce the issue using a smaller sample. Following your directions, I submitted the sample through the contact link you provided. I think I've also narrowed the issue down a little further. The exception is only thrown when we obfuscate the NuGet package, which we're doing to protect IP.

I just sent an Email containing the projects. Let me know if you have any issues with them.

Thanks for the sample solution. It's very useful that you were able to submit all components relevant to the problem. I appreciate the effort it would have taken you to whittle this down.

The problem appears to be caused by the obfuscation of the NuGet package. The obfuscator being used here appears to be designed to create an assembly that is structurally invalid in a way that cannot be processed by IL manipulation tools but can still be executed by the CLR.

After NCrunch builds your project, it loads the freshly built assembly into memory and generates a series of hashes from the assembly content that are later used for impact analysis. This allows NCrunch to detect when changes are made to the assembly's IL so that the appropriate tests can be run intelligently. Because this assembly inherits from a type in the Nuget package, the obfuscated Nuget package assembly also needs to be loaded and considered by the hash routine. This results in obfuscated code being read from an invalid assembly and an exception is thrown.

Unfortunately I can't think of a reliable way for me to introduce a workaround for this in NCrunch itself. This is because the assembly is actually invalid and designed not to be read by anything but the CLR itself. It might be possible to rig NCrunch to simply ignore assemblies that it has problems reading, but this would not be a stable solution as the data could also be read incorrectly, resulting in strange downstream problems.

There are several ways you can work around this problem:
1. Consider compiling the Nuget package without the obfuscator for use in your NCrunch environment
2. Set your 'Impact detection mode' solution-level NCrunch setting to 'Watch Text'. This will disable IL-hashing for impact detection purposes, so the obfuscated assembly may not need to be loaded.
3. Consider using a different obfuscator that can still protect your code without structurally invalidating the assembly itself. Your existing obfuscator may also have configuration options allowing you to choose the features you want to use for obfuscation.
4. Avoid inheriting from types in the Nuget package. It might be possible to use the package through referencing code elements as long as you avoid inheritance (I haven't tested this).