This is a follow-on from https://forum.ncrunch.net/yaf_postst2828_Warning-when-trying-to-build--net-standard-projects-on-grid-server.aspx
I have a simple .net core project. When I try to build it on my grid-server machine I get this error...
C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets (234): Package NUnit, version 3.12.0 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
Following the advice in the earlier thread, I've tried running the grid-server under my local account but see the same issue...
13:28>& 'C:\Program Files (x86)\Remco Software\NCrunch Grid Node Server\NCrunch.GridNode.Console.exe'
Now initialising NCrunch Grid Node using console host. Version is 4.4.0.12
[13:29:37.471-?-1] Node server started - listening on port 41141
Grid node successfully started and is listening for connections on port 41141
[13:29:37.6433-Core-3] Client connection accepted from 192.168.0.12:64563
[13:29:37.6454-Core-3] Creating server-side handler for 192.168.0.12:64563
[13:29:37.6463-Core-3] Describing self to 192.168.0.12:64563
[13:29:41.9228-NodeProcessor-26] ERROR (Build): Tests: C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets (234): Package NUnit, version 3.12.0 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
If I copy the solution folder to the grid server and run it locally, the restore completes and it compiles fine...
13:36>dotnet build
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 30.97 ms for C:\work\gomark\Tests\Tests.csproj.
Restore completed in 30.97 ms for C:\work\gomark\gomark\gomark.csproj.
gomark -> C:\work\gomark\gomark\bin\Debug\netcoreapp3.1\gomark.dll
Tests -> C:\work\gomark\Tests\bin\Debug\netcoreapp3.1\Tests.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.22
Note that I'm running dotnet build from the same powershell console that I previously invoked
the gridnode from.
I'm guessing the gridnode is picking up some setting that is different to the local environment. Is there some way I can look for discrepancies? (I suppose there really might be a path length issue but I have placed the snapshots area at "C:\NC" to mitigate against this.
Usually, NCrunch should copy missing Nuget packages over from the client to the grid node. Because we can't rely on the node having a reliable connection to Nuget, we don't attempt to restore the packages directly.
Normally, the packages are stored under the local user profile at C:\Users\USER\.nuget\packages. Can you check if the NUnit package is listed there? If not, the simple workaround may be to copy the package over from your client machine manually.
Thanks Remco, that's really useful information - I hadn't realised the nuget packages were copied across. It appears that what has happened is that VS has referenced the NUnit package from C:\Microsoft\Xamarin\NuGet
I'm not sure why VS has set up this alternate package source but here's some further information in case it turns out to be more general problem...
- Both client and server machines have VS 2019 Preview (16.7.0 p6) installed
- One of the solutions we build (manually) on both machines contains a Xamarin phone app so the Xamarin SDK has been installed
- The "problem" solution does _not_ contain any Xamarin projects - it's just a .net core console app and associated test project
- The test project was created by just using the built-in VS "NUnit Test Project (.Net Core)" template
- The reference path can be determined by right clicking on NUnit in the project Dependencies/Packages and selecting "properties". It cannot be determined from the project file. It's not obvious how this path is determined by VS. Running nuget.exe from the developer shell doesn't list it...
Anyway, as you say, copying the Nunit package into the "standard" cache manually appears to resolve it so everything is working nicely now - thanks again. :-)
Anyway, as you say, copying the Nunit package into the "standard" cache manually appears to resolve it so everything is working nicely now - thanks again. :-)
Great to hear you are up and running. I'm not sure exactly what is happening here .. I suspect that there may be an environment variable or build property in play that is redirecting your Nuget references on the client machine. This may then be causing problems for NCrunch working out which packages should be uploaded and where to put them. Working this out would require detailed inspection of an environment where it is happening, which isn't really worth the trouble in your case given the ease of working around the issue. It's possible we'll hit this in future with the next VS version .. we'll keep an eye out for it.