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

Notification

Icon
Error
Nuget restore failing for grid server
Options
Previous Topic Next Topic
NeilMacMullen
#1 Posted : Wednesday, July 29, 2020 12:42:59 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 12/15/2016(UTC)
Posts: 55
Location: United Kingdom

Thanks: 29 times
Was thanked: 12 time(s) in 11 post(s)
This is a follow-on from https://forum.ncrunch.ne...cts-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...

Quote:
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...

Quote:
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...

Quote:
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.

Thanks for any light you can shed on this!

Back to top
Remco
#2 Posted : Wednesday, July 29, 2020 11:33:24 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi, thanks for sharing this issue.

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.
Back to top
1 user thanked Remco for this useful post.
NeilMacMullen on 7/30/2020(UTC)
NeilMacMullen
#3 Posted : Thursday, July 30, 2020 9:16:04 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 12/15/2016(UTC)
Posts: 55
Location: United Kingdom

Thanks: 29 times
Was thanked: 12 time(s) in 11 post(s)
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...


Quote:
10:11>C:\Users\neilm\Downloads\nuget.exe locals all -list
http-cache: C:\Users\neilm\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\neilm\.nuget\packages\
temp: C:\Users\neilm\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\neilm\AppData\Local\NuGet\plugins-cache


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. :-)

Neil
Back to top
Remco
#4 Posted : Friday, July 31, 2020 8:31:09 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
NeilMacMullen;14897 wrote:


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.
Back to top
1 user thanked Remco for this useful post.
NeilMacMullen on 7/31/2020(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.047 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download