When we push a new version of a NuGet package to our NuGet feed the package will appear in the file system on the NuGet server. The NuGet feed API and in visual studio, however only update roughly every hour so we may have to wait up to an hour for new packages to show. Is there a way to force update the NuGet feed to accurately depict what is in the file system?
I've encountered very similar issue, after publishing new package version to private TeamCity NuGet feed it hasn't appeared in visual studio immediately. It took time to update.
However, new package version itself was available via request:
http://<teamcityserver>/guestAuth/app/nuget/v1/FeedService.svc/Packages(Id='<packageId>',Version='<newPackageVersion>')
For example:
http://test:8111/guestAuth/app/nuget/v1/FeedService.svc/Packages(Id='TestPackage',Version='1.0.1')
I resolved it by cleaning local NuGet cache
via
Tools → Options → NuGet Package Manager → General → Clear all NuGet cache(s)
or
dotnet nuget locals all --clear
See related answer:
https://stackoverflow.com/a/42665980/2793919
Related
Due to the usage of Babel, that require us to host ourself the package manager on a private repository, we are using Azure Devop as a source of our packages.
But now when we look for any package that is not yet somewhere in the solution, we end up with a "No packages found":
Here we were looking for "roslynator"
If I do this same request in a brand new project. No issues at all, I find the packages.
but we have nuget.org correctly specified in the upstream sources:
And the whole team is listed as contributor. I cannot find any error anywhere when we are fetching the packages. I tried to execute the command Install-package Roslynator. The commands succeed, and then I'm able to see the package in the GUI of visual studio(and in the web console of visual studio).
Seems to be an issue on Visual studio level, but I cannot understand what is causing it?
According to the steps in the Consume NuGet packages in Visual Studio document:
If you're using upstream sources, any packages from upstream sources that haven't been saved to your feed yet (by using them at least once) won't appear in the Package Manager search result. To install those packages:
Copy the Install-Package command from the public registry (NuGet.org).
Select Tools then NuGet Package Manager to open the NuGet package
manager.
Paste the command into the Package Manager Console and select run.
So this is the expected behavior and your steps are correct.
Update:
If you want to find all packages in nuget.org, you need to choose nuget.org as source and search packages instead of using your Azure DevOps sources:
According to this document:The nuget.org upstream source allows you to merge the contents of nuget.org into your feed such that the NuGet client can install packages from both locations without making multiple search queries. Enabling upstream sources also automatically enables saving of packages you use from the upstream source.
If you dislike this behavior (and who wouldn't) you can up-vote this Visual Studio Developer Community issue: Allow search upstream sources on Azure Artifacts
And I can confirm as of 12/28/2022 this is still an issue. :-(
I've configured the Package Management extension in my VSTS project and added nuget.org as an upstream source.
I've configured my Visual Studio project to use my VSTS feed as the only package source.
I've installed a nuget package from nuget.org via my VSTS feed using Install-Package on the Package Manager Console. I'm expecting the package to then show up in my VSTS feed, but it's not.
Are my expectations wrong, or am I missing a step?
I had previously installed this nuget package so it was in my local nuget cache. I cleared the local nuget cache (Tools->NuGet Package Manager->Package Manager Settings->General->Clear All NuGet Cache(s)) and re-installed the package, and then saw it pull through my VSTS feed and cache it there.
While installing the NuGet packages from the NuGet package manage, having configured multiple NuGet package sources in VS2017, the NuGet client tries to retrieve the package in all the configured NuGet sources and returns messages like "Not Found".
I have configured the below NuGet sources in my NuGet.Config,
I have tried to restore the Newtonsoft.Json NuGet package from the command prompt by using the nuget restore command. The NuGet client will try to retrieve the Newtonsoft.Json NuGet package from my custom NuGet feed, which does not contain the Newtonsoft.Json package and returns a NotFound message in the output:
However the package is restored perfectly without issues. But why does the package manager search all the sources which are configured and prints not found errors even it found it in the first NuGet source?
Why does the NuGet client try to retrieve in all configures sources? Is this a bug from NuGet? I am using Visual Studio 2017 (15.4) and NuGet package Manager (4.4.0).
No, it's not a bug.
When the NuGet client is doing a restore and sees you have a dependency on some package, it has no way of knowing which feed the package exists in. In the past, the NuGet client would query each source in order, but at some point it was changed to query all sources concurrently and use the first successful response.
There are also several scenarios where you would want to get a package that is available on nuget.org, from a source other than nuget.org. One example is you might have a private feed with commonly used packages on the same network as your build servers, so that package restore is as quick as possible and more resilient to network outages.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.
How to gracefully stop support of NuGet package in nuget.org repository? Actually I moved the package to another NuGet channel (e.g. moved https://www.nuget.org/packages/my_old_package/ to https://www.nuget.org/packages/my_new_package/). And want to notify existing subscribers that they should switch.
Currently, I consider the following solutions:
Publish last build with description like "This package is no longer
supported. Switch to other package..."
Simply delete package - not sure how will it affect customers.
What approach can you recommend?
You can unlist the old NuGet package so it will not be found when searching for packages. Unlisting is what happens when you delete the package either from the command line using NuGet.exe or from the gallery on nuget.org.
With the NuGet package being unlisted existing users can still use that package. Restoring the package will still work since the NuGet package still exists.
Notifying existing users of the NuGet package not being supported is not a feature of NuGet. If you need that you would have to implement yourself. For example, you could add a readme.txt to the latest NuGet package which informs the user that this package is now deprecated and they should be using a different NuGet package. The readme.txt will automatically be opened by Visual Studio when the package installed. The only problem here is that this approach is incompatible with unlisting the NuGet package. The NuGet package with the readme.txt would still need to be listed on nuget.org.
Another approach, which may or may not be a possibility, is to have your old NuGet package simply install the other NuGet package. So the old NuGet package has no content itself but just has a dependency on the other NuGet package.
Of these approaches I think I would just unlist all the versions of the old NuGet package. You could also update the package description on nuget.org by editing the metadata directly on the site to indicate the old NuGet package is deprecated.