[BUG] dotnet restore failed when api.nuget.org is blocked in firewall and custom feed is provided #558
Comments
JohanSpannare
changed the title
|
This is, indeed, a problem. Trying to use Microsoft.Build.Sql (sqlproj) from a build server with custom nuget feeds enabled, and having the same issue. |
|
This looks like an authentication problem, when the NuGet-based MSBuild project SDK resolver contacts the feed it doesn't have any access. Its a little confusing, do you have a source named "nuget.org" that's really an artifactory URL? This error says But you don't have nuget.org configured? Keep in mind that the NuGet-based MSBuild project SDK resolver can only be configured via NuGet.config and setting MSBuild properties to configured feeds is not supported. So whatever feed is in the NuGet.config is what will be used. It finds the NuGet.config nearest the project or solution file. |
|
Hi @jeffkl, in this example the feed is named nuget.org and pointing towards an Artifactory instance. Same problem also happen when using Azure DevOps as feed source. I have an open support case with Microsoft, i added you to the mail conversation a while ago. You should be able to read the mail thread and also see the 3 demos i had with Microsoft Support.
You mentioned above that NuGet.config is the file that will be used as source in SDK resolver. I will state that that is incorrect, whatever you set in NuGet.config is not respected by the resolver. That is the problem!. Below you can see the result of
To reproduce this error set a hosts record for api.nuget.org like below Add this two lines to C:\Windows\System32\drivers\etc\hosts
Make sure your global NuGet.config at C:\Users\UserName\AppData\Roaming\NuGet\NuGet.Config do not have any proxy configuration set. |
|
Okay can you help me understand better? You do not have access to nuget.org from the agent but you have a proxy server and your NuGet.config contains that proxy server? In your Do you have only one feed configured and your NuGet.Config looks like: <?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="http_proxy" value="http://proxyServer:8080" />
<add key="http_proxy.user" value="proxyUser" />
<add key="no_proxy" value="*.myDomain" />
</config>
<packageSources>
<clear />
<add key="artifactory" value="https://artifactory.XXXX.com/artifactory/api/nuget/nuget.remote/" />
</packageSources>
</configuration>If you the |
|
I'm wondering where NuGet is being told to contact <?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="http_proxy" value="http://127.0.0.1:8080" />
<add key="http_proxy.user" value="proxyUser" />
<add key="no_proxy" value="*.myDomain" />
</config>
<packageSources>
<clear />
<add key="artifactory" value="https://artifactory.com/artifactory/api/nuget/nuget.remote/" />
</packageSources>
</configuration>That |
|
I have to confess that this is not an BUG, its a user side error. While trying to understand where the api.nuget.org was coming from. I ran process monitor on dotnet process. While reading the output i saw this line... The developer had by mistake added an nuget.config file to the project directory. So whatever nuget setting that was configured to the root directory nuget file, was overwritten by the project level nuget config. After deleting this file i can confirm that the resolve of SDK dependencies is now working as expected! Thank you @jeffkl for being inquisitive and therefor rubber-ducking me! |
|
Sorry for the bad experience. At the end of a normal NuGet restore, all of the NuGet.config files that were used are printed to the console. But when the SDK resolver runs, it doesn't print that sort of info. That might be a good feature so I filed an issue at NuGet/Home#13602 that maybe I can include in a future update to the SDK resolver. |
Background
We are running Azure DevOps Server on-prem. And for security reason we are not allowing internet access from our build agents. Instead all agents are configured to use internal nuget feeds configured in Artifactory mirroring nuget.org.
In below example i have disabled the access to api.nuget.org on my local laptop. This is being able to reproduce the error locally.
Example
nuget sourcesdotnet buildExpected result
I expect that any nuget feed configured should be used when resolving SDK´s as well for custom nuget packages.
Work around
To get around this error, i manually have to preload the nuget cache. This so when MSBuildSdks is trying to resolve and dependencies. It do not need to go externally to download the package via api.nuget.org that is blocked.
The text was updated successfully, but these errors were encountered: