Issue when using NCrunch with Code Contracts and Fody

Hi,

Just found an issue when using the following tools together (Resharper works fine):
1. NCrunch 1.45.0.12
2. Code Contracts for .NET 1.5.60409.11
3. Fody 1.13.6.1
4. ProperyChanged.Fody 1.36.2.3
5. EmptyConstructor.Fody 0.4.1.1

Here is an example project that can reproduce the issue:
https://dl.dropboxusercontent.com/u/46508238/forum.ncrunch.net/2013-04-24-TestNCrunch.zip

Steps to reproduce the issue:

1. Create a new class library;
2. Enabled Code Contracts (check "Perform Runtime Contract Checking" in the Code Contracts tab of the project property);
3. Add the following NuGet packages:
- Fody
- PropertyChanged.Fody
- EmptyConstructor.Fody
4. Add the following code to the project:

    public class Factory<T> where T : class
    {
    }

    public class PersonFactory : Factory<Person>
    {
        public PersonFactory(Serivce service)
        {
        }
    }

    public class Serivce
    {
    }

    public class Person
    {

    }

5. Enable NCrunch. NCrunch will fail to build the project:

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
   at Mono.Collections.Generic.Collection`1.get_Item(Int32 index)
   at Mono.Cecil.SignatureReader.GetGenericParameter(GenericParameterType type, UInt32 var)
   at Mono.Cecil.SignatureReader.ReadTypeSignature(ElementType etype)
   at Mono.Cecil.SignatureReader.ReadGenericInstanceSignature(IGenericParameterProvider provider, IGenericInstance instance)
   at Mono.Cecil.SignatureReader.ReadTypeSignature(ElementType etype)
   at Mono.Cecil.MetadataReader.GetTypeSpecification(UInt32 rid)
   at Mono.Cecil.MetadataReader.LookupToken(MetadataToken token)
   at Mono.Cecil.MetadataReader.ReadTypeMemberReference(MetadataToken type, String name, UInt32 signature)
   at Mono.Cecil.MetadataReader.ReadMemberReference(UInt32 rid)
   at Mono.Cecil.MetadataReader.GetMemberReference(UInt32 rid)
   at Mono.Cecil.MetadataReader.LookupToken(MetadataToken token)
   at Mono.Cecil.Cil.CodeReader.ReadOperand(Instruction instruction)
   at Mono.Cecil.Cil.CodeReader.ReadCode()
   at Mono.Cecil.Cil.CodeReader.ReadMethodBody()
   at Mono.Cecil.Cil.CodeReader.ReadMethodBody(MethodDefinition method)
   at Mono.Cecil.MethodDefinition.<get_Body>b__2(MethodDefinition method, MetadataReader reader)
   at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
   at Mono.Cecil.MethodDefinition.get_Body()
   at #=qbCmuRvwaGkeXlmfkBrrDt2OpT3YbqniMuDX$uZfVVIuuBACWbReTmYk8hIOGsE9h1kdlhRy5cuDvy5QV9KD$Jw==.#=qJ1JIUwIg144RKup11LFaTNAe1anTDwGnrDm5cMlS_Uc=(Collection`1 #=q_ElH4htm2hWWVEUWlMhL1A==)
   at #=qbCmuRvwaGkeXlmfkBrrDt2OpT3YbqniMuDX$uZfVVIuuBACWbReTmYk8hIOGsE9h1kdlhRy5cuDvy5QV9KD$Jw==.#=qGmgu4wJa2bkl6RzNAmzt2VWKi$9NyTFPmoHoHZ6o0yk=(IEnumerable`1 #=qh$xhOUB0ZU$EX1XZxbMRFw==)
   at #=qbCmuRvwaGkeXlmfkBrrDt2OpT3YbqniMuDX$uZfVVIuuBACWbReTmYk8hIOGsE9h1kdlhRy5cuDvy5QV9KD$Jw==.#=qhsY5EnqIn13pEJTo5htTVxtQcGcs0VOQgCyE$VrBaow=()
   at nCrunch.Compiler.StaticManipulation.BuiltAssembly.Instrument(ComponentSourceLineMap sourceLineMap, IDictionary`2 instrumentationDirectivesByCodeFileId, IDictionary`2 codeFileIDsByFilePath, Boolean proxyProcessIsActive, Int32 componentId, IInstrumentationFilter[] instrumentationFilters)
   at nCrunch.Compiler.RemoteBuildRunner.#=qc19uOgHz4bbS00fHoJcJ86FdDfZxNpBz6hs6SLcoDgg=(ComponentBuildParameters #=qmVSC1mocuqkeMyG6RiWA7A==, String #=q6HotKBtAzAJ5NhAIJpJMWErw8$oIjiUT0yL0fTvBG1s=, BuildOutput #=qeo8ShH4FE1FNzdVk_FG0_g==, String #=qRmPlD1GldENhQyyoQ5tYKKyaUsmzaLiSqv0FdoKZIHA=, String[] #=qftBQ99WoQMP8nKBadgDENHqcE_v2YLLk_k2_mOUUIoM=)
   at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)

Hi Yang,

This looks like a clash between NCrunch's instrumentation and Code Contracts' instrumentation.

I'll note it down to be fixed in the next maintenance release. Thanks for sharing the sample code, this was very helpful in identifying the problem!


Cheers,

Remco

Just uninstalled Code Contacts from my machine. I think I won't try it again for a long time.

It greatly slows down build time, sometimes it didn't throw exceptions when it should, and have compatibility issues with some tools.

Edit: Fixed typo.

You can configure builds with different levels of analysis and exception rewriting.

My current arrangement is 3 build modes:
Debug: All runtime contracts, no static analysis
Release: Public runtime contracts only (just the ones with an explicit exception specified), no static analysis
Analysis: All runtime contracts, static checks enabled

I do run tests against both runtime configurations.

The static analysis certainly does take a long time, and it unfortunately does get less attention if it isn't part of the normal builds, but I like debugging to be fast too.
There's different sets of checks and assumptions you can include/exclude for the static analysis as well, these along with what checks and assumptions are specified, and how many will have a big effect on the actual time.

Ncrunch has its own options to turn it off as well. (Ncrunch defaults static to off, and runtime to as-is, I think?)

Not to say it's for everyone, and it does have its shortcomings, but I've found it to be quite nice.

Thanks for your response.

I used "Debug: All runtime contracts, no static analysis" (tried static analysis before but unbearably slow, so turned it off), but still too slow on my machine (it's a slow machine built several years ago).

I plan to upgrade my machine later this year then test again.

Cheers