NCRUNCH 3.3: don't resolve nuget packages in project with project.json

I get always "Build failure" in project with project.json. Please help!
[img=(- BROKEN LINK -)]Screenshot[/img]

VS2015, Nuget 3.5

Hi, thanks for sharing this issue.

Is this a project that you can share with me? I'd really like to take a closer look at how it is put together. You can submit it via the contact form.

Yes, off course!

Thanks for sending through the sample project. This looks to be a regression in v3.3, where some of the .NET core integration handling has damaged NCrunch's ability to resolve Nuget package references during build time.

If handling these references is required for your project, I recommend rolling back to v3.2 (it works in this build). A fix will be included in v3.4. Sorry for the trouble.

We use project.json for NuGet references - 3.2 grid servers handles this just fine. In 3.4 and in 3.7 we see different, but broken, behaviours.

If my local username is "frsheara", in 3.4 I see NuGet trying to find packages in C:\WINDOWS\system32\config\systemprofile\.nuget\packages (the .nuget in the user as which the service is running). In 3.7 [edit: and 3.9], I see NuGet trying to find packages in _my_ .nuget/packages directory on the server. In both cases these directories don't exist.

Is this a related issue to the .Net Core integration work you mentioned?

Hi, thanks for sharing this problem.

What you're experiencing is unlikely to be related to the other changes discussed in this thread. When a solution is transferred to a grid node, there is considerable complexity in negotiating Nuget packages between client and server. In theory, the client should identify the package dependencies and pass this over as metadata to the server. The server can then check its own locally installed packages, and request download of any packages that are missing. The result of this is package synchronisation over the grid that takes account of different package install directories. The projects on the server side are then rerouted to the different package installation paths.

In practice, it's not so simple. .NET seems to have an ever growing number of ways in which Nuget packages are expressed and handled by the tooling. NCrunch needs special handling for every case, and there are ongoing attempts to plug the holes in many of the NCrunch versions released in the last few years. Since v3.2, much of this code has been restructured to resolve various newly discovered problems.

It's likely you've discovered a use case that NCrunch isn't yet able to handle. Is there any chance you can share a test solution with me that I can use to troubleshoot it?

Sure. Here's a very small project that fails to build (NCrunch 3.4 client, same on server): (- BROKEN LINK -)

In the zip I have added the NCrunch diagnostic output from a similar run, and a zip of that workspace.

The server fails the build with this error:

****************** BUILD OUTPUT FROM 'connect-ci-15' ******************

..\..\..\..\..\..\..\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets (140, 5): The package NCrunch.Framework with version 2.27.0.3 could not be found in C:\WINDOWS\system32\config\systemprofile\.nuget\packages. Run a NuGet package restore to download the package.

NCrunch: The following files were used when building this project locally but do not seem to exist on the remote grid node responsible for building this project:
C:\Users\frsheara\.nuget\packages\NCrunch.Framework\2.27.0.3\lib\NCrunch.Framework.dll

Often this can be caused by configuration differences between your client machine and the grid node, in which case the installed SDK directories may be different between machines. If you are experiencing consistent problems when building this project on the grid node, the missing files listed above are worth investigating as they may highlight SDKs required on the grid node that have not yet been installed. Please note that this is not necessarily an error case as projects very often build successfully on grid nodes with only a subset of the client machine's installed SDKs.

Thanks for the sample project.

I've just check this and found that it works correctly for me under NCrunch v3.9. Can you confirm if you see the same behaviour?

Yep, same behaviour in 3.9 - the server looks in the ~/.nuget/ directory for packages, where ~ is the service's user account:

..\..\..\..\..\..\..\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets (140, 5): The package NCrunch.Framework with version 2.27.0.3 could not be found in C:\WINDOWS\system32\config\systemprofile\.nuget\packages. Run a NuGet package restore to download the package.

NCrunch: The following files were used when building this project locally but do not seem to exist on the remote grid node responsible for building this project:
C:\Users\frsheara\.nuget\packages\NCrunch.Framework\2.27.0.3\lib\NCrunch.Framework.dll

FrankShearar wrote:
NCrunch: The following files were used when building this project locally but do not seem to exist on the remote grid node responsible for building this project:
C:\Users\frsheara\.nuget\packages\NCrunch.Framework\2.27.0.3\lib\NCrunch.Framework.dll

Ok, this warning is a red herring. NCrunch creates these warnings when something doesn't work. It just creates a list of files that were used on the local machine vs the grid node, and lets you know of any differences in case there's an SDK you don't have installed.

I think the real problem here is a grid node package synchronisation issue. You're using NCrunch.Framework on your local machine, where it's installed under your Nuget packages. On your grid node, this file doesn't exist. There is a known problem at the moment where NCrunch isn't always transferring Nuget packages to the grid node correctly, so instead of copying the file over to the node, it just tries to build on there and assumes the package is present.

The workaround for this problem is to manually copy the required Nuget packages over to the grid node (under their expected paths for the grid node service), or to copy your solution to the grid node service and execute "msbuild /t:Restore mysolution.sln" or open the solution in VS to restore the packages.