System.InvalidOperationException: Failed to resolve type: System.Action

Seems like this issue is related to the latest VS update and not nCrunch? I downgraded to version 1.45 of nCrunch (which was working fine) and it is now broken there as well.

Is there anyway to get around this? nCrunch is unusable at this point for me. A workaround would be great.

Specifically this is a build failure on a WinPhone8 project in VS 2012.

Here is the stack trace.

System.InvalidOperationException: Failed to resolve type: System.Action
at Mono.Cecil.Mixin.CheckedResolve(TypeReference self)
at Mono.Cecil.MetadataBuilder.GetConstantType(TypeReference constant_type, Object constant)
at Mono.Cecil.MetadataBuilder.AddConstant(IConstantProvider owner, TypeReference type)
at Mono.Cecil.MetadataBuilder.AddParameter(UInt16 sequence, ParameterDefinition parameter, ParamTable table)
at Mono.Cecil.MetadataBuilder.AddParameters(MethodDefinition method)
at Mono.Cecil.MetadataBuilder.AddMethod(MethodDefinition method)
at Mono.Cecil.MetadataBuilder.AddMethods(TypeDefinition type)
at Mono.Cecil.MetadataBuilder.AddType(TypeDefinition type)
at Mono.Cecil.MetadataBuilder.AddType(TypeDefinition type)
at Mono.Cecil.MetadataBuilder.AddTypeDefs()
at Mono.Cecil.MetadataBuilder.BuildTypes()
at Mono.Cecil.MetadataBuilder.BuildModule()
at Mono.Cecil.ModuleWriter.<BuildMetadata>b__0(MetadataBuilder builder, MetadataReader _)
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
at Mono.Cecil.ModuleWriter.BuildMetadata(ModuleDefinition module, MetadataBuilder metadata)
at Mono.Cecil.ModuleWriter.WriteModuleTo(ModuleDefinition module, Stream stream, WriterParameters parameters)
at Mono.Cecil.ModuleDefinition.Write(Stream stream, WriterParameters parameters)
at Mono.Cecil.ModuleDefinition.Write(String fileName, WriterParameters parameters)
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.#=qja5Lz4WZy5j3MkNOHZhbaZpln7tx7srxEXb9K2GS7$U=.#=q22O$JgAsJTR3Hpdj0eFfVncIWom9AscQSwFKIwxgZu4=()
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.#=qDxMNFyFjhW6PesDGrPnDGw==(Action #=qmoTnfrFpYptfR_uC0zp4vw==)
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.Instrument(ComponentSourceLineMap sourceLineMap, IDictionary`2 instrumentationDirectivesByCodeFileId, IDictionary`2 codeFileIDsByFilePath, Boolean proxyProcessIsActive, Int32 componentId, IInstrumentationFilter[] instrumentationFilters)
at nCrunch.Compiler.RemoteBuildRunner.#=qLSOS1zuHnrzTx60jFaBRcIB2DcGcLszbneFFQNEvoBg=(ComponentBuildParameters #=q7KmSCDFrq8HbZ914RXx0qQ==, String #=ququTFsUvva1GB55pjo4xWUkBrHmgU24wfaApaZnR3Co=, BuildOutput #=qPH_Jd$V_IxrVJ0GZ$pHtGQ==, String #=qBr7BagygrWJoCOCDUUaMmQ_g$ymjxu2aPOxBqomomB0=, String[] #=qqlfITOgjD00t0l5VBAuXbHwLiH_$KXxXOG1qgbTM2OQ=)
at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)

Hi,

Thanks for sharing this issue.

As Windows Phone 8 is based on Silverlight, officially NCrunch isn't expected to support it until Version 2. With that in mind, it's surprising to me that this actually worked for you previously.

Anyway, I always welcome reports about these sorts of issues as by fixing them we do get closer to fully supporting these frameworks, which of course NCrunch eventually must do. It looks as though the Windows Phone 8 SDK introduces several overrides around the resolution of assemblies, which NCrunch currently doesn't cater for. This causes all sorts of problems during instrumentation of the assemblies and while tests are being executed.

I haven't been able to reproduce the exact error you've experienced - so this fix is somewhat speculative, but I'm wondering if you'd be interested in trying the build below to see if this solves the problem:

http://downloads.ncrunch.net/NCrunch_VS2012_1.47.0.1.msi.

I'm keen to hear how it goes!


Cheers,

Remco

Hi Remco,


Thanks for the test build. This does indeed fix my issue and I can now use nCrunch! :)

It did used to work fine for me so I am not sure where a regression would have occurred that broke it (however, like I said the version that used to work for me doesn't anymore so I think it was a VS issue or .NET framework issue).


Would love to see this fix integrated into an update in the future. For now I am going to use this build.


Thanks again.

Great to hear! I have a feeling that this issue probably appeared as the result of a code change to the affected project (i.e. a System.Action parameter added to a public method). The problem would have been lurking for some time, and we just needed the right arrangement of code to surface it.