Build failure with InvalidCastException.

Hello Everybody,
I am getting the following exception when building one of my C# projects:

System.Exception: Unable to add type: AdjustingSensingHeadPlugin.BlockFactory due to exception: System.InvalidCastException: Specified cast is not valid.
at Mono.Cecil.SignatureWriter.WritePrimitiveValue(ElementType type, Object value)
at Mono.Cecil.MetadataBuilder.GetConstantSignature(ElementType type, Object value)
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.#=q5vpF3zzm5zqKWCqcfbybS1u$DyuX6VxOlACprKPOhos=.#=qiXU_bNfvoheaf1Kj33xMBnSi6oPkLBSuauav99oaDfM=()
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.#=q7yp7R2vCg7OHrM_sd9tAMw==(Action #=qkWXG3M1rwpI6MlmUHfcmCA==)
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.Instrument(ComponentSourceLineMap sourceLineMap, IDictionary`2 instrumentationDirectivesByCodeFileId, IDictionary`2 codeFileIDsByFilePath, Boolean proxyProcessIsActive, Int32 componentId, IInstrumentationFilter[] instrumentationFilters)
at nCrunch.Compiler.RemoteBuildRunner.#=qgKRq1fUIr1IxXJQPqNrCdDnHIt2sr6IitqvDmQ34$FU=(ComponentBuildParameters #=qSQJL7L_EzBixm2aAhyr7pQ==, FilePath #=qOmmMHYYQpG_c7PD9b7zxTo$tlPrG1q1r5uLHobVtx_o=, BuildOutput #=qJ9z5KdrHTj3gG8xDkzDJpg==, DirectoryPath[] #=q8jp6VSMp9XO0CSWIyQa4EFaTpoE$OOwCDUtQgSXJHRQ=, FilePath[] #=qajJdvqLBN9egZtr61G5Ke8CCzie8cGDvhY6gfRfVdH2OyTQgx5OMzyo3KrStLz9q)
at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)

What might be wrong?

Hi, thanks for sharing this issue.

It looks like the type shown above (AdjustingSensingHeadPlugin.BlockFactory) contains some kind of IL structure that NCrunch's instrumentation can't handle. It's been a while since I've seen this happen - there must be something quite unusual about this class.

Check the nature of the parameters being used for methods on this class, especially parameters that may make use of generics or default values. If you manage to isolate and share with me the C# syntax that is causing the exception to appear, I may be able to get you a fixed build of NCrunch that can handle it.

Turning off the 'Instrument output assembly' project-level configuration setting should allow you to work around the problem until we can sort out a proper solution. Note that this will disable code coverage tracking for the project.

Hello,
Sorry for so late reply. I seems to figure out what language construct caused the issue.
In the base class I have a method:
protected virtual TBlock GetDefaultBlock<TBlock>([Optional] TKPBlockType dClassificationBlockType) where TBlock : BaseBlock, new()

In the derived class (AdjustingSensingHeadPlugin.BlockFactory - the one that causes the problem) I override this method:
protected override TBlock GetDefaultBlock<TBlock>(TKPBlockType dClassificationBlockType = 0)
This signature causes the problem.

I can change this signature to
protected override TBlock GetDefaultBlock<TBlock>([Optional] [DefaultParameterValue(TKPBlockType.DCombinedFaultClassification)] TKPBlockType dClassificationBlockType)

and problem disappears.

Hope this helps.
Vadim.

Fantastic, thanks for providing this. I'll see if I can get it fixed!

Sadly I've been unable to reproduce this problem using the signatures you've provided above. I think there must be another element here that I'm missing.

I realise that you've already found a workaround to this problem, so I'm hesitant to ask for more of your time on this. If you're still experiencing problems and would like me to investigate for you, is there any chance you can provide me with a code sample that reproduces the problem via the contact form?

Remco wrote:Sadly I've been unable to reproduce this problem using the signatures you've provided above. I think there must be another element here that I'm missing.

I realise that you've already found a workaround to this problem, so I'm hesitant to ask for more of your time on this. If you're still experiencing problems and would like me to investigate for you, is there any chance you can provide me with a code sample that reproduces the problem via the contact form?

I'm also consistently seeing this problem building one of our projects. The class that is causing the problem contains an interface that represents something like a variant type so it has almost every kind of .NET type imaginable hanging off it. I can try hacking stuff out into a stand-alone repro, but if you have the PDB for the version of Cecil you include with NCrunch, I could use that to narrow down exactly what type it's trying to inspect when it goes boom.

I found a few references to this issue in Cecil that might also be relevant.

Thanks! If you can get me a standalone repro, then there is a really good chance I can fix this problem.

Unfortunately the version of cecil used by NCrunch has seen some fairly extensive modification, so troubleshooting it via cecil may not be the easiest approach.

Even a compiled assembly that can reproduce the problem will probably be enough for me to attack it.

Remco wrote:Thanks! If you can get me a standalone repro, then there is a really good chance I can fix this problem.

I was expecting quite a difficult repro, but the first class I copied to my stand-alone demo reproduced the problem :) All you need is a 'uint' enumeration that is supplied a default value as a parameter somewhere (I guessing that's the constant that the Cecil callstack is complaining about). Using the code below as an example, if I change the enumeration type to 'int', it works, and if I remove the default parameter value, it works. Let me know if you need anything further (I'm using NCrunch 2.9.0.8 for reference).

[Flags]
public enum CecilBreakerEnumeration : uint
{
    Value1 = 0x20000000,

    Value2 = 0x40000000,

    Value3 = 0x10000000
}

public class CecilBreaker
{
    public CecilBreaker()
    {
    }

    public CecilBreaker(CecilBreakerEnumeration cecilBreakerEnumeration = 0)
    {
    }

    public CecilBreakerEnumeration Flags { get; set; }
}

Perfect! Thanks for this. I've now reproduced the problem and will see if I can get it fixed :)

Ok! Here's a fixed build :)

http://downloads.ncrunch.net/NCrunch_Console_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_Console_2.10.0.1.zip
http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.10.0.1.zip
http://downloads.ncrunch.net/NCrunch_VS2008_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.10.0.1.zip
http://downloads.ncrunch.net/NCrunch_VS2012_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_VS2012_2.10.0.1.zip
http://downloads.ncrunch.net/NCrunch_VS2013_2.10.0.1.msi
http://downloads.ncrunch.net/NCrunch_VS2013_2.10.0.1.zip

Thanks Remco, the 2.10.0.1 build worked for me in Visual Studio 2013.