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
Does turning on the 'Prevent signing of output assembly' NCrunch project-level configuration option for these two F# projects resolve the issue?
NCrunch will manipulate assemblies after they are built (this includes F# assemblies). The manipulation invalidates any signature on the assembly that was generated from a signing action. Normally NCrunch will re-sign the assembly itself, though it's possible that something specific to F# is preventing this from happening in your situation.
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.
Ok - this is definitely a signing issue then. I know you've stated that none of the assemblies in your solution are signed, but I have a feeling there is something going on here.
I've tried creating a sample solution in the same structure as you've described, but the problem isn't appearing for me. I suggest setting your Log Verbosity (global setting) to Detailed, then examining the output of the Build Task for one of the F# projects inside the Processing Queue Window. Do you see anything in the build log related to signing of the output assembly, or passing of any kind of key file into the F# compile step?
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?
Thanks for sending through the logs. There's no signing going on here, no keys, nothing. I'm out of ideas. Is there any chance you can narrow this down to a code sample you can share with me? If I can reproduce the problem, there is a very good chance I can provide a solution that won't involve turning off the intrumentation.
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.
I have managed to reproduce this in a simple example, will send the files via the support link.
The issue is that the F# project is using a type provider (FSharp.Data). As mentioned above, this has always worked fine with VS2013 and NCrunch, provided that the following is added to the F# project file:
(NuGet does not add this reference, since at runtime only FSharp.Data.dll is required, while at compile time FSharp.Data.DesignTime.dll is also required)
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.
mjmckp wrote:I see, thanks. Do you think it would be straightforward to reproduce the bug outside NCrunch so that it can be reported to Microsoft?
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.
I've managed to find a solution to this. The problem was in the way that NCrunch has been handling a strange mscorlib assembly reference that exists only when an FSharp type provider is in use.
I've prepared a fixed build if you'd like to give it a try: