Itiviti/gradle-nuget-plugin

nugetRestore fails with automatically downloaded NuGet under LocalSystem

Opened this issue · 4 comments

DKroot commented

CI services, for example default Jenkins setup, often runs under LocalSystem account.

In that scenario, nugetRestore fails with the following error using the latest plug-in version 2.14 and automatically downloaded NuGet 3.4.3:

:nugetRestore (Thread[main,5,main]) started.
:nugetRestore
Executing task ':nugetRestore' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.
Restoring NuGet packages 
Starting process 'command 'C:\Windows\System32\config\systemprofile\.gradle\caches\nuget\3.4.3\NuGet.exe''. Working directory: C:\Jenkins\jobs\iRePORT-Dev\workspace Command: C:\Windows\System32\config\systemprofile\.gradle\caches\nuget\3.4.3\NuGet.exe restore -NonInteractive -Verbosity normal
Successfully started process 'command 'C:\Windows\System32\config\systemprofile\.gradle\caches\nuget\3.4.3\NuGet.exe''
:nugetRestore FAILED
:nugetRestore (Thread[main,5,main]) completed. Took 2.736 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nugetRestore'.
> Process 'command 'C:\Windows\System32\config\systemprofile\.gradle\caches\nuget\3.4.3\NuGet.exe'' finished with non-zero exit value -2146232576

If I switch to system NuGet 3.4.4 on the PATH, nugetRestore works just fine. BTW, I'd document how to do that: I had to read source code to see if this was an option. I set up NUGET_HOME in System environment variables, and that fixed the issue.

Also, prior to switch to LocalSystem we had Jenkins running under Windows user account and this is not an issue in that scenario.

timotei commented

What about NuGet 3.4.4 with the gradle plugin? Also, the executable seems to return a non-zero code, isn't there any output? (If you run with --info or --debug).

DKroot commented
  • I tried --info and --debug and nothing useful comes out of the output
  • I can't get gradle-nuget-plugin to download 3.4.4 because of the case difference. Also see issue #43.
kuniss commented

Additional information to figure out the problem:
In fact, we got the same error

:nugetRestore FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nugetRestore'.
> Process 'command 'C:\Windows\System32\config\systemprofile\.gradle\caches\nuget\3.4.4\NuGet.exe'' finished with non-zero exit value -2146232576

when upgrading the JVM version Jenkins and within Gradle is running on from 7 to 8.
We are quite sure, this is the only change we did to the project before rebuilding it as we just have merged back a branch with no changes on the trunk and the branch was before built without errors with the same build logic but Java 7 backed.

I tried to figure out why Java 7 backed Gradle build worked before. It seems, with Java 8 the system profile path (where also the gradle.properties file is taken from) has been changed from "C:.gradle" to "'C:\Windows\System32\config\systemprofile\.gradle".
When I'm trying to start 'C:\Windows\System32\config\systemprofile.gradle\caches\nuget\3.4.4\NuGet.exe' by double clicking, I'm getting an error pointing to https://support.microsoft.com/en-us/help/2715633/shim-errors-for-the-.net-framework-version-and-platform-support
However, if copying the same executable to elsewhere, if runs fine without that error.

Setting up NUGET_HOME in System environment variables pointing to the elsewhere copied NuGet.exe as mentioned by @DKroot worked for me too. However, I would like to have the out-of-box behavior as we had it with Java 7. Any idea how to achieve this?

I guess, there must be a Windows system configuration which allows to start .NET applications from within the localsystem's profile path. But I did not find any resource about that on the net...