Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Issue with VS2015 RC
Options
Previous Topic Next Topic
mjmckp
#1 Posted : Wednesday, May 13, 2015 1:51:41 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
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
Back to top
 |  Edit by user
Remco
#2 Posted : Wednesday, May 13, 2015 2:46:25 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this issue.

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.
Back to top
mjmckp
#3 Posted : Wednesday, May 13, 2015 3:11:14 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
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.
Back to top
Remco
#4 Posted : Wednesday, May 13, 2015 3:29:52 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Does disabling the 'Instrument output assembly' setting for the F# projects make any difference?
Back to top
mjmckp
#5 Posted : Wednesday, May 13, 2015 3:39:35 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Yes, that fixes it (although does that mean I lose line-by-line execution times?)
Back to top
Remco
#6 Posted : Wednesday, May 13, 2015 4:31:56 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
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?
Back to top
 |  Edit by user
mjmckp
#7 Posted : Wednesday, May 13, 2015 5:00:47 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
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?
Back to top
Remco
#8 Posted : Wednesday, May 13, 2015 5:09:05 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
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.
Back to top
mjmckp
#9 Posted : Wednesday, May 13, 2015 6:00:55 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
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.
Back to top
1 user thanked mjmckp for this useful post.
Remco on 5/13/2015(UTC)
mjmckp
#10 Posted : Monday, May 25, 2015 12:46:11 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
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:

<Reference Include="FSharp.Data.DesignTime" Condition="'$(NCrunch)' == '1'">
<HintPath>..\ConsoleApplication1\packages\FSharp.Data.2.2.2\lib\net40\FSharp.Data.DesignTime.dll</HintPath>
</Reference>

(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)
Back to top
Remco
#11 Posted : Tuesday, May 26, 2015 12:07:57 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
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.
Back to top
mjmckp
#12 Posted : Tuesday, May 26, 2015 12:57:43 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
I see, thanks. Do you think it would be straightforward to reproduce the bug outside NCrunch so that it can be reported to Microsoft?
Back to top
Remco
#13 Posted : Tuesday, May 26, 2015 1:05:51 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
mjmckp;7366 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.
Back to top
 |  Edit by user
1 user thanked Remco for this useful post.
mjmckp on 5/26/2015(UTC)
Remco
#14 Posted : Tuesday, June 2, 2015 9:54:26 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Back to top
mjmckp
#15 Posted : Wednesday, June 3, 2015 7:41:55 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Thanks Remco, will give it a go tomorrow
Back to top
mjmckp
#16 Posted : Thursday, June 4, 2015 9:17:35 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/13/2015(UTC)
Posts: 10
Location: Australia

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
That's working fine now, thanks again
Back to top
1 user thanked mjmckp for this useful post.
Remco on 6/4/2015(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.084 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download