Azure devops: error NU1101: Unable to find package xxx. No packages exist with this id in source(s): nuget.org

4
votes

I have a package I push to a private nuget feed. Then a few other projects reference these packages. All is good, except when I specify a wildcard, that only works in vs, but apparently not when restoring via an azure devops build:

this works:

<PackageReference Include="MyLibPackage" Version="1.0.0.114" />

but I get the unable to find package error on:

<PackageReference Include="MyLibPackage" Version="*" />

snippet of the dockerfile the restore task in azure devops runs:

# Install the Credential Provider to configure the access
RUN wget -qO- https://raw.githubusercontent.com/Microsoft/artifacts-credprovider/master/helpers/installcredprovider.sh | bash

# Configure the environment variables
ENV NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED true
ENV VSS_NUGET_EXTERNAL_FEED_ENDPOINTS "{\"endpointCredentials\": [{\"endpoint\":\"$feed\", \"password\":\"$pat\"}]}"

WORKDIR /src

COPY ["MyProject/MyProject.csproj", "MyProject/"]

RUN dotnet restore -s "$feed" "MyProject/MyProject.csproj"
2
docker.net-coreazure-devopsnuget
The restore runs in the docker build when specifying an explicit package version, but not for an always-latest version range? – Josh Gust
@JoshGust yes that is correct – Elger Mensonides
Is this a total build failure when using the wildcard? I know that nuget checks all sources in parallel, but it should only fail hard if none of the sources found a match. – Josh Gust
@JoshGust unfortunately yes, it can't find any package. There's only 1 source, and one private library, of which I just want the latest. – Elger Mensonides
Does a range of 1.* change the behavior? – Josh Gust

2 Answers

2
votes

Azure devops: error NU1101: Unable to find package xxx. No packages exist with this id in source(s): nuget.org

I do not have much experience with Docker, I am not sure if this issue comes from docker container or dotnet restore itself.

But since you said in the comment:

Basically everyting except a hard version number fails.

So, I would like provide a workaround to resolve this issue, you can check if it works for you:

Since we have to use the hard version number, we could add one more command to update the package to the latest version, the command line like following:

RUN dotnet add package MyLibPackage -s "$feed"

And set the WORKDIR in the dockerfile where the project file is.

@Elger Mensonides, Thanks for Elger`s contribution for the correct command line.

If we do not specify the version in the command line, it will add the latest package to the project.

Check the document dotnet CLI – how to update a NuGet package and add a new NuGet package for some details.

Hope this can helps.

-1
votes

I suggest using normal problem solving techniques and remove unnecessary complications to isolate the root cause of the problem. In your case, take docker out the mix and use Azure DevOps built-in functionality to restore and build. However, in this case it might mask the problem because the NuGet task allows you to specify a source feed, which doesn't appear in any nuget.config file (the task will create a temporary nuget.config file with the source). If you can't tell, I'm not a fan of using Docker to build. It's a great technology for running services, but I've seen too many people lose hours or days of productivity when they can't get their build tools to work correctly in a container.

Anyway, given the list of sources given in the error message contains only nuget.org, it means you don't have a nuget.config file in your repo that lists your private feed. If you added your private feed using Visual Studio's tools->options->nuget->sources, that only modifies your user profile nuget.config. This means it only works on your computer, none others. You need to create a nuget.config and commit it into your repo, so that the CI machine will be able to use it. Using dotnet new nugetconfig will give you a template good to start with.