Home: Package update not found when updating via Visual Studio Solution

[deadlydog]

This problem occurs occasionally when trying to update nuget packages from the NuGet package manager within Visual Studio 2015, but only occurs when updating packages at the solution level; that is, right click on the solution (not the project), and choose "Manager NuGet Packages for Solution...". It will find an update for a nuget package just fine and list the latest version, but after you select the projects to update and click the Install button, the installation fails with a message similar to the following in the Output window.

Package 'DansUtilityLibraries.CSharpLibrary' is not found in the following primary source(s): 'https://www.nuget.org/api/v2/'. Please verify all your online package sources are available.

Trying to do the install repeatedly just results in it failing with the same error.

Sometimes closing VS 2015 and reopening it will fix the problem and the install will succeed, but not all of the time. I have found that the most reliable work around is to right-click the project and choose "Manager NuGet Packages..." and do the update from that window, for each project that needs the update. For some reason updating the nuget package at the project level does not have the same problem; it only occurs at the solution level.

I didn't think to try doing the update from the NuGet Package Manager PowerShell Console, so I'll give that a try as well next time it happens and update this ticket with the results.

I first ran into this problem months ago when I updated to VS 2015 and NuGet Package Manager 3, but now after installing VS 2015 Update 1 and NuGet Package Manager 3.3.0.167 the problem persists. As I mentioned above, the problem does not happen every time; it seems to be sporadic.

[yishaigalatzer]

@deadlydog thanks for the feedback. We will try to get a repro and get it fixed. Are you seeing this for any particular package or packages that where just freshly pushed to nuget.org? What feed are you using? Can you share a fiddler trace when this issue happens again?

[deadlydog]

Now that you mention it, I have typically seen it when trying to download my own packages that were pushed very recently to nuget.org. If I encounter the issue again I'll try and provide a fiddler trace.

[yishaigalatzer]

This makes "some" sense, what you see is probably an incorrect propagation of pushed packages showing up in the search results but not yet available to download (this could happen if one server updated faster than another, and you hop between them). This is something we are working on improving.

Still just to verify it a fiddler trace will be of great help.

[deadlydog]

Hi guys, so I was seeing this problem again and brought up fiddler. The new update that I just published showed up right away, but when trying to update I got the error. After bringing up Fiddler and hitting the Update button again, VS was not making a connection attempt at all to NuGet; it would just report the error. I flipped my package source to my work's internal repo and saw it make connections to it to do a search for updates, but when I flipped it back to nuget.org, again no connections. So even though I was getting the "loading" bar, it seems it was just searching it's local cache for updates, and not trying to go out to nuget.org. So I closed VS and reopened it, and this time everything worked. I'm guessing that closing VS invalidates VS's local cache so that it actually attempts to go to nuget.org to get the package. I hope that helps.

It seems pretty easy to reproduce if you guys want to give it a shot. Just upload a new package version to nuget.org and try and update to it within a few minutes of the upload (I had VS open while uploading the new version).

[deadlydog]

Um, not sure how I unassigned @feiling from this ticket when I added my comment, but I'm not able to reassign him...

[yishaigalatzer]

No problems, @feiling left so it is just a github quirk. We now understand this issue, and it makes total sense, caching is expected. We should move this issue out as a lower priority item and deal with busting caches in this case.

[hakito]

I think the problem is, that the nuget client caches http request for a package for 30 minutes:

https://github.com/NuGet/NuGet.Client/blob/5902aadde9f8a43b96c166b793101c23d6646dcf/src/NuGet.Core/NuGet.Protocol.Core.v3/RemoteRepositories/RemoteV2FindPackageByIdResource.cs#L134

We have the same problem with internal nuget packages for continuous integration builds. It would be great to disable this cache.

[yishaigalatzer]

@hakito this is not the case in 3.3, this is new code. And we have a way to deal with it by resetting the cache on install.

We are running out of time for 3.4, I'm moving to 3.5 for John to look at

[cocogorilla]

I just recently started a completely fresh f# project, attempted to download fscheck off nuget... this message fired.

Why is it checking our private repository?... its not available unless I'm connected through firewall. But fscheck is public, not on our private repos.

Severity Code Description Project File Line Suppression State
Error Exception 'System.AggregateException' thrown when trying to add source 'https://nuget.privaterepository.com/nuget'. Please verify all your online package sources are available. 0

I was unable to install the package through GUI at solution/project level, nor use the packagemanager console until I removed our internal nuget server as a source. Then it installed just fine.

[yishaigalatzer]

Cocogorilla this looks like a different issue. Can you open a new issue and provide a good set of repro steps and the version of nuget you are using? Thanks!

[cocogorilla]

Will do.
On Fri, Apr 15, 2016 at 3:18 PM Yishai Galatzer [email protected]
wrote:

Cocogorilla this looks like a different issue. Can you open a new issue
and provide a good set of repro steps and the version of nuget you are
using? Thanks!

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/NuGet/Home/issues/1827#issuecomment-210667133

[cocogorilla]

Reported issue:
#2598

[jainaashish]

@deadlydog We had some code fixes around cache busting n resetting it, so can you try to repro this with latest nuget 3.4.3? And if you can still repro, then share the repro steps.
I tried to repro it as mentioned above, like pushed a package version to nuget.org and within minutes tried to update it through nuget UI (which was already opened) and it worked fine with latest build.

[jainaashish]

Closing as non-repro with 3.4.3 onwards. Feel free to re-open in case this issue surface again.

[deadlydog]

Just a note that I have finally got around to retesting this and also cannot reproduce it, so I believe the problem is fixed. Thanks!

[mmulhearn]

FYI, I've been seeing this exact issue in the past month or so. Switching between sources, uninstalling and reinstalling are some work arounds, but not 100%. Pushing my own packages up to VSTS and then it takes like 15 minutes to finally get it to install.

[mmulhearn]

You can see Cs.DataAccess has an update, but it says it can't find the package.

[Vrungar]

I am getting the same thing after I update my nuget packages on VSTS. It works fine after the initial upload, but after you publish an update it starts displaying that error.

[Ericmas001]

I got this.
The "indexing in progress" on Nuget.org is gone. New version has been pushed 30 minutes ago.
Nuget package manager shows me that it's ready to update, but clicking on it gives me the error

Severity    Code    Description Project File    Line    Suppression State
Error       Package '...' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json,C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. Please verify all your online package sources are available (OR) package id, version are specified correctly.            0   

[DrWala]

+1 I'm facing the same issue with an update being available but I can't download it

[zorgoz]

+1 Same here.
To me, it looks a caching related issue. I might have found kind of a workaround.

Try following steps:

1. Create a solution with a library project (let's call it L01)
2. Add another library project to the solution (let's call it D01)
3. Make a nuget package from L01 (version 0.0.1)
4. Push the package to your VSTS feed (probably same for other feeds too)
5. Manage packages for project D01 and browse your feed
6. Package L01 v0.0.1 will be listed
7. Add it to project D01, it will work
8. Edit L01 nuspec file and change version to 0.0.2
9. Build and push the new package
10. Go back to project D01 and refresh the package list. The update will be shown.
11. Try to update. It will fail with the error message you know.
12. Now go to folder %localappdata%\NuGet\v3-cache (or equivalent)
13. Locate the folder corresponding to your feed and open it
14. Locate list_l01.lib_index.dat (where l01 is the package name) and delete it
15. Go back to project D01 and try to install the update. It will succeed.

[bvirkler]

Same issue for me. Another workaround is clearing the nuget cache:
Package Manager Settings->General->Clear All NuGet Cache(s)

[ttaylor29]

The comment by: zorgoz commented on May 11 fixed my issue.

[xavierlaffargue]

Same issue for me, thanks zorgoz it's work !

[jainaashish]

@mishra14 can you please look into this and reopen if this still repros.

[jainaashish]

oops didn't mean to open it right away....

[tomRedox]

Yep, same issue for me on vs 2017 15.8.4, @zorgoz 's solution fixed it for me.
Edit: as per @RyanMathewson we're getting this with Azure Devops Nuget server.
Also, I think the behaviour we are getting is that it works the first few times, then fails, and then I have to clear out the cache folder manually in Windows Explorer each time from then on until I close and reopen VS.

[Kranthi1547]

Yes, this issue still exists. @zorgoz solution fixed the issue in my case.

[RyanMathewson]

Same issue on VS 2017 15.9.2, specifically when pulling from packages published to our Azure Devops Nuget server. @zorgoz 's solution worked.

[jasonracey]

Expanding on the workaround provided by @bvirkler here's more detail:

1. Tools > NuGet Package Manager > Package Manager Settings
2. Select NuGet Package Manager option
3. Click Clear All NuGet Caches(s) button

[jainaashish]

Reopening to run with an investigation

[johnfercher]

Same problem here, Clearing All Nuget Caches solved the issue.

[ntrpnr]

Same issue with VS2017 15.9.8. Nuget package published to Azure Devops.

[alohaninja]

Same issue with VS2017 15.9.10. Nuget package published to Azure Artifacts - credential cache must be getting corrupted during the upgrade. VS installer should probably just do this action for you. 😉

I didn't have any other issues reading packages from the v3 feeds outside VS IDE.

Manually Resetting Nuget Cache in VS IDE after Updating

[samneefs]

I have the error also, but use another workaround:
I only get it on the solution level, when using the "Install" button, however, when you are on the "Updates" panel, there is also an "Update" button: using this button doesn't give the error.

After using alohaninja's solution: I can now use the "Install" button again.

[CrossBound]

Apparantly this is still an issue for VSTS nuget feed in Visual Studio 2019. I was just having the same issue with an internal package that I had updated. the fix suggested by @bvirkler in regard to clearing the nuget cache worked for me

[jaywha]

Still an issue in VS Pro 2019 v4.8.03761
Running an enterprise image of Windows 10
Just cleared the NuGet cache and all is well again.

[MichielCornilleESC]

Noticed this today
Vs Enterprise 2017 Version 15.9.12 , Azure DevOps private NuGet feed. (Own package)

[aortiz-msft]

Sorry to hear that this continues to be an issue for folks. We tried this on 16.6 Preview 1 and weren't able to reproduce the problem. These are the steps that we followed:

1. Launch VS and create a solution with multiple projects (e.g. ASP.NET Web Application (.NET Framework)).
2. Right click on the solution and choose “Manage NuGet Packages for Solution…”
3. Go to “Updates” tab (make sure there are several non-latest packages installed).
4. Select the project to update and click “Install” button.

Did we miss something? If someone could help confirm that this issue continues to be present in 16.6 Preview 1 or later, that'd be great!

Thanks!

[bgiromini]

Sorry to hear that this continues to be an issue for folks. We tried this on 16.6 Preview 1 and weren't able to reproduce the problem. These are the steps that we followed:

1. Launch VS and create a solution with multiple projects (e.g. ASP.NET Web Application (.NET Framework)).
2. Right click on the solution and choose “Manage NuGet Packages for Solution…”
3. Go to “Updates” tab (make sure there are several non-latest packages installed).
4. Select the project to update and click “Install” button.

Did we miss something? If someone could help confirm that this issue continues to be present in 16.6 Preview 1 or later, that'd be great!

Thanks!

More broadly, any package that is recently published to a nuget feed will not be updated until some time after. So if you publish a nuget package to Azure DevOps, then try to update the package in another solution, Visual Studio will not see the new package.

[zivkan]

@bgiromini the scenario you described sounds like a duplicate of https://github.com/NuGet/Home/issues/3116. If this whole issue is about the same scenario, packages not downloadable for about 30 minutes after publishing to a feed, then one of the two issues can be closed as a duplicate.

[ntrpnr]

I've seen this less often recently. It's is most likely related to newly published packages - but clearing the Nuget package cache is always the instant fix for me.