I have a solution with 92 projects that works fine with VS2013 and NCrunch 2.15.0.9, but with VS2015 RC and the same NCrunch version, two of the projects fail with errors like the following:

NCrunch: This project was built on server '(local)'
CSC (0, 0): Metadata file 'C:\Users\Mat\AppData\Local\NCrunch\81888\12\SomeRepo\src\SomeAssembly\bin\Debug\SomeAssembly.dll' could not be opened -- Invalid public key.

UPDATE: It seems to be only happening for C# projects which are referencing F# projects

Hi Remco, thanks for the quick reply. Unfortunately, changing that configuration option makes no difference. Btw, none of the assemblies in the solution are signed.

Yes, that fixes it (although does that mean I lose line-by-line execution times?)

I've sent the build logs via the support link above. I don't see anything relating signing of the output assembly, or any key files passed into the compile step. Are you sure it's to do with signing if switching off the instrumentation fixes it?

I have another C# project of the same type which references a different F# project, and that works fine, so I don't think that is sufficient to reproduce the problem.

Meanwhile, I have two independent C# projects which reference different F# projects which are giving the above error.

So, I'm not sure where to start in creating a reproduction of the issue, but will give it a go tomorrow.

Thanks for sending through the code sample. The solution is behaving for me exactly as you've described it.

The problem itself is being thrown up by the Roslyn compiler (CSC) when it tries to negotiate the reference to the FSharp library. Signing the dependency makes no difference at all. It isn't clear to me why the compiler feels it needs to verify this assembly's signature, nor why the verification is failing.

My assumption at this stage is that a change in behaviour introduced in Roslyn (vs the old unmanaged compiler) has caused CSC to take issue with a certain metadata arrangement. Currently the only known use case where this seems to be a problem is the one you've identified (referencing an instrumented FSharp assembly that makes use of a type provider).

This will be a difficult and time consuming issue to troubleshoot, so I'm afraid that I'm unable to give a time-frame on a solution right now. I recommend staying with VS2013 for the time being, or otherwise working with instrumentation turned off on your FSharp assembly.

It depends upon the nature of the problem. There is a possibility that the type provider results in a valid IL sequence that NCrunch is somehow mangling with its instrumentation (this is what I hope is happening), in which case I'll be able to solve the problem with a code fix.

If it really is a bug in Roslyn itself, then reporting it to MS would be the normal procedure .. though implementing a workaround would also be a preference.

The problem with this issue is that because it's being reported down the line and very obscurely, it's likely to be very hard to actually understand it and pin it down. We're in real luck that MS have open sourced Roslyn. Without this, I'm not sure if trying to solve the problem would be feasible.

Thanks Remco, will give it a go tomorrow