Nuget restore called from C# Script failing
TeamCity Enterprise 2023.11.4 (build 147586)
We are trying to abstract away some of our build steps for C# projects into meta-runners and C# scripts. One of our meta-runners uses the C# script runner to run a script which in turn runs a nuget restore command. Some of the packages that need to be restored are on our own on-prem nuget server which is separate from TeamCity. When just using the built-in nuget restore step, the Nuget Feed Credentials Build Feature works well to authenticate.
However, this new configuration is not working. At the beginning of the nuget restore, we get a FileNotFoundException for System.Runtime. Then, when it's searching for each package, our private nuget feeds can't be accessed, and we get an error saying that CredentialProvider.TeamCity failed.
Starting: "C:\Program Files\dotnet\dotnet.exe" C:\TeamCity\buildAgent\tools\TeamCity.csi.1.0.6\tools\net7.0\any\dotnet-csi.dll @C:\TeamCity\buildAgent\temp\agentTmp\options2.rsp
12:10:04 Starting: C:\TeamCity\buildAgent\tools\TeamCity.csi.1.0.6\tools\net7.0\any\dotnet-csi.dll @C:\TeamCity\buildAgent\temp\agentTmp\options2.rsp
12:10:04 in directory: C:\TeamCity\buildAgent\work\64743ded94928fc6
12:10:05 JetBrains TeamCity C# 10.0 script runner 1.0.6 net7.0
12:10:06 Command: C:\TeamCity\buildAgent\tools\NuGet.CommandLine.5.11.0\tools\nuget.exe
12:10:06 Command args: restore "C:\TeamCity\buildAgent\work\64743ded94928fc6\MySolution.sln" -NoCache
12:10:06
12:10:07 MSBuild auto-detection: using msbuild version '17.9.5.7608' from 'C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\bin'.
12:10:09 Restoring NuGet package MyPackage.1.0.0-18.dev.
12:10:09 Restoring NuGet package MyOtherPackage.2.0.0-8.dev.
12:10:09
12:10:09 Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
...
12:10:11 http://OurNugetServer/index.json: Problem starting the plugin 'C:\TeamCity\buildAgent\plugins\nuget-agent\bin\credential-plugin\net5.0\CredentialProvider.TeamCity.dll'. Plugin 'CredentialProvider.TeamCity' failed within 1.733 seconds with exit code -532462766.To try to reproduce this, I went as far as logging onto the build agent, installing the TeamCity.csi tool, and running the same C# script with the same arguments that are run from the server. However, the nuget restore works perfectly when I do this. I am at a loss as to what could be going wrong. Any help would be greatly appreciated!
Please sign in to leave a comment.
Update: We have found that the build succeeds when the projects in the solution are SDK-style. We are migrating to SDK-style piece by piece but aren't finished yet.
I'm glad you found a solution that works for you. Please let me know if you encounter any issues implementing it.
Best regards,
Anton
Hi Anton,
Sorry, my comment wasn't very clear. That's not a solution for us - we need these builds to work for both SDK-style and non-SDK style. That is actually a big reason we went to meta-runners and C# scripts, because we had too many build steps that were dependent on the result of prior build steps, and it was getting to be too hard to manage with built-in conditional build steps. I was hoping that the bit of info that we don't see this error on SDK-style projects would be a clue for someone to be able to provide some insight.
Could you try adding the `teamcity.nuget.credentialprovider.disabled=true` configuration parameter and share the results?
Best regards,
Anton
Hi Anton,
That worked! At least for a sample size of one. Can you explain what that did?
Thanks!
Jordan
The core of the issue may be in the NUGET_PLUGIN_PATHS environment variable, which is not present in your build configuration. Could you try to delete the configuration parameter that you added and add this environment variable (even with an empty value), and check the behavior again?
Best regards,
Anton
That also worked. Is that what you would recommend we implement as the permanent fix?
I think going with the environment variable solution would be safer in the long run (some hidden, internal, properties may be changed with the updates).
The problem is that when the build configuration is designed like you described, this environment variable is not created (it should be created automatically when running nuget restore separately). It is used in the credentials provider plugin, but for such cases as yours, the value is not required; it is just needed so the plugin does not crash during the startup.
Best regards,
Anton
Thanks so much for all the help and extra explanation!