Dotnet restore with dotnet 5 fails against internal nuget feed
Installed dotnet 5.0.402 on a build agent but when I run dotnet restore it fails with access denied (401 not authorized) against the internal package feed in Teamcity. From Configuration Parameters on the agent I can see there is no DotNetCredentialProvider for net5
DotNetCoreSDK5.0.402_Path /usr/share/dotnet/sdk/5.0.402
DotNetCoreSDK5.0_Path /usr/share/dotnet/sdk/5.0.402
DotNetCredentialProvider1.0.0_Path /opt/buildagent/plugins/nuget-agent/bin/credential-plugin/netcoreapp1.0/CredentialProvider.TeamCity.dll
DotNetCredentialProvider2.0.0_Path /opt/buildagent/plugins/nuget-agent/bin/credential-plugin/netcoreapp2.0/CredentialProvider.TeamCity.dll
DotNetCredentialProvider3.0.0_Path /opt/buildagent/plugins/nuget-agent/bin/credential-plugin/netcoreapp3.0/CredentialProvider.TeamCity.dll
DotNetCredentialProvider4.0.0_Path /opt/buildagent/plugins/nuget-agent/bin/credential-plugin/net46/CredentialProvider.TeamCity.exe
Is that the problem and if so how do I fix it? This is not something I have had to deal with previously.
Please sign in to leave a comment.
Yes, I figured that out, don't really see why there is a such tight coupling between the agent and the server though? I think an update for the agent should be enough to get this running. Anyway, thanks for the replay.
Hello,
The NuGet support doesn't just have the agent-side part but also the server-side part, hence the coupling.
Technically, you can try to skip upgrading and only update the NuGet Support plugin (download the latest TC version tar.gz distro, extract the
webapps/ROOT/WEB-INF/plugins/dotNetPackagesSupport.zipfile from it and install it on the server as an external plugin). However this was not tested with older versions of TeamCity, so it is possible that it does not work properly.Thank you,
Guilherme
This comes back and haunt me and I really need to wrap my head around this since I can't find anybody else having issues with this. It always happens around the time for a new dotnet-release and also this time (dotnet7). My builds for apps running dotnet7 fails due to no credential-plugin for that specific release. Last time there was a new release that I had missed, this time I cant find any newer release than 2022.10 and my agents only have credential-plugin for dotnet6. Do I really need to wait for a new Teamcity release to make this work without the "hack-solution" mentioned by @Guilherme Barbosa above?
Sorry for the delay, other work and vacation. So here is our build log Upload id: 2023_02_01_HhozvjuyU7JzjykCL4TNzs (file: bmx-infra_Logging_Package_34.log.zip) If we use mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim to run the "Restore Test packages" step it fails with NU1301: Unable to load the service index for source. However, if we change to mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim restore works with no issue. To be clear we run these steps in docker-wrapper.
Had any time to look at the logs Anatoly Cherenkov? Would really appreciate it. Thanks // Jakob
Excuse me but I'm coming back to this all the time and it feels like either we have something wrong in our setup or we are just doing it the wrong way. Since we never fixed it last time and just kept using dotnet 6 to not spend time on this. But now with latest Teamcity (2023.05) and dotnet7 I thought that I should give it a try again but till same error. I have tested many different thing but restore against our own feed in Teamcity with in mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim or any other dotnet 7 distribution simply don't work. I just get NU1301: Unable to load the service index for source. and I assume it's a 401 in the background even though logs don't say that last part. THe docs say that the Nuget feed credentials provider shouldn't be need for the internal feed, I have tested both with and without. Restore step as of now looks like this, please help me =)
As a workaround, please try using the 7.0-bullseye-slim image.
Credentials for the built-in feed are indeed not required in the build configuration settings.