azureasp.net-coreazure-devopsnugetazure-deployment

error NU1102: Unable to find package NuGet.Frameworks with version (>= 4.9.3)

I'm getting this error when I try to build a .NET Core solution with Azure DevOps:

error NU1102:  Unable to find package NuGet Frameworks with version (>= 4.9.3)
error NU1102:   - Found 33 version(s) in http://nuget.bentley.com/nuget/Default [ Nearest version: 4.7.0-preview1-4986 ]

The error occurs in the Cake script when a NuGet restore is being executed by dotnet.exe CLI:

Executing: "d:/vsts/a/_tool/dncs/2.2.100/x64/dotnet.exe" restore "./src/StorageRegistryPortal.sln" --source "http://nuget.bentley.com/nuget/Default"

It tries to restore the NuGet packages from the solution file before throwing the NU1102 error above:

 Restoring packages for d:\vsts\a\2921\s\src\StorageRegistryPortal\StorageRegistryPortal.csproj...

Nothing in my solution is referencing this "NuGet.Frameworks" package. So, I wonder if it is the "dotnet.exe" CLI itself that depends on this nuget package before it can restore the rest of the NuGet packages. Also, this only happens in AzureDevops. When I execute the build/cake script on my local PC, it is able to successfully restore all of the nuget packages with no issues.

I've already tried adding a "Use Nuget 4.9.3" task to the build pipeline, but I get the same error.

NOTE: If I remove that "Use Nuget 4.9.3" task, then the error changes to (>= 4.7.0). So, it appears to be looking for the Nuget.Framework that matches the current version of nuget.exe but not finding it.

Here is the screenshot of my build pipeline setup: enter image description here

Solution

  • I was finally able to resolve this issue. It turns out there was a breaking change from the nuget.org folks which caused our internal nuget server to fail to serve the 4.7 and 4.9.3 versions of NuGet.Frameworks. This is an essential nuget library which is required by dotnet.exe to restore nuget packages. For .net core projects, that framework needs to be version 4.7 or higher. Anyway, the resolution was that we had to make adjustments to our internal nuget server to account for the changes from nuget.org.