ArgumentOutOfRangeException after upgrading to 2.8

Hi,

Love the tool but have encountered a problem after having upgrading to v2.8.0.36.

One of my projects that previously built find with Ncrunch and currently builds fines with VS2013 is complaining with the following stack...

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.ReadFatMethod()
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 #=qtu9p_KdCU5UqfZtvAXYPNjxHtYimFrCqzpf8cbEaEB$k5ZfpPU53Fw18p1fWw4AA2Wu2TRq9C8SLmzKSw6tRIQ==.#=qwhgeisoOJjlYalN1__wtWpC6jEMmRuYKXDfMIgpfD$k=(Collection`1 #=qe61ldccANrgB_ga_wauT7w==)
at #=qtu9p_KdCU5UqfZtvAXYPNjxHtYimFrCqzpf8cbEaEB$k5ZfpPU53Fw18p1fWw4AA2Wu2TRq9C8SLmzKSw6tRIQ==.#=qcZ9wY_hOoC8nHlOgMURwv7gDuwAJjPFoiVrChKUS3S8=(IEnumerable`1 #=q6P0plZuo2T3bawRShtYmyA==)
at #=qtu9p_KdCU5UqfZtvAXYPNjxHtYimFrCqzpf8cbEaEB$k5ZfpPU53Fw18p1fWw4AA2Wu2TRq9C8SLmzKSw6tRIQ==.#=q9JFECJ6PbYVORJ_MahzthKau85wuSrWeFNaDJagwObU=()
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.Instrument(ComponentSourceLineMap sourceLineMap, IDictionary`2 instrumentationDirectivesByCodeFileId, IDictionary`2 codeFileIDsByFilePath, Boolean proxyProcessIsActive, Int32 componentId, IInstrumentationFilter[] instrumentationFilters)
at nCrunch.Compiler.RemoteBuildRunner.#=qdg4CSZCIbzfR8d1AZiALKNud6iMqvPJsWvcOchLTZ4g=(ComponentBuildParameters #=qhDbHx1P3yaY3IohmKZqdKg==, FilePath #=qACV7_d$5p5Ra6u22PG5aZew37Lu5DHU8ZdWB_iWqtBA=, BuildOutput #=q0rSIgXU8Kdj9pwqqLcVyQQ==, DirectoryPath[] #=qk0Unv8F$iQSGkoY9m05ke4_GVgG4K5ORJKhcM84Sd5o=, FilePath[] #=qXhM3sq7D7_8BSSHaPwxMBdzDw4Icc6W7$F706sXjLnJc1YCMBsiqMzCVrBEaNyIL)
at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)


I've tried various config options, but all result in the same error.

Any clues?

thanks!

Matt

Hi Matt,

Thanks for sharing this issue. This appears to be an instrumentation problem caused by an IL arrangement that NCrunch/Cecil isn't able to understand. Somewhere in your code there will be a generic type declaration using a structure that is triggering this problem. If you can manage to narrow it down to a code sample that can reproduce the problem, I stand a good chance of being able to fix it for you. NCrunch has been fairly well trashed over most codebases, so the arrangement causing this is likely to be only rarely used and may involve new features of the .NET framework and it's possible that this is compiler generated code (i.e. async blocks etc).

Interestingly, v2.8 hasn't introduced any changes to the instrumentation or the code around it. Was your upgrade coming from 2.7? Or was there an earlier version that you were running? I'm wondering if it's possible that this has been triggered by a chance in your codebase rather than an install of the new version.


Cheers,

Remco

Hi Remco,

I managed to narrow it down to a recent code change, it was the placing of the [ToString] attribute (a Fody extension) onto a POCO class.

However, I tried to recreate it in a fresh project and couldn't but that seemed to fix it in this instance.
If I manage to recreate then I'll post it here,

Thanks,

Matt

Hi Matt,

There's a good chance that this is indirectly being caused by the Frody extension. As it is an IL manipulation tool, Frody is able to create IL sequences that aren't typical for the C# or VB.NET compilers. This makes it possible to create code that may be semantically correct yet structurally abnormal.... if this makes any sense.