Turns out that not all of the packages were being included in source control. Once I added in the missing package folders to source control I was able to move forward.

A vulnerability version range can be: the literal string (any) empty string (equivalent to (any)) single single, single single, single, single single, single, single, single etc. A single vulnerability version range can be: version >version >=version <version <=version >version <version >=version <version >version <=version >=version <=version The format of version is defined by the feed type.

In this case, you will need to give the "Anonymous" access to push packages to the feed. You can configure this from Admin > Tasks.

As of v4, ProGet will no longer support packages pulling packages with dependencies from the UI. This is because it's "impossible" to do without visual studio's context (target framework, .net version, etc).

Hmm, sounds like a NuGet/VS bug... definitely worth sharing this with them!

It's working again now, there was an issue with one of our feed URL's. But I would expected an HTTP 404 error instead of an HTTP 500 error then..

ProGet does not support that versioning scheme. This was only recently added in Nuget v3.5; we may add it at some point, but we need to support older clients and need to keep the older rules for now.

thanks we managed to find it as nuget was packing the release and debug files over the top of each other for some stupid reason in just the packages generated for this project. no idea why it did not affect any other solution on our build server

The Feed Clean-up task, which is run from the service on a schedule you define in Admin > Tasks, will clean up these. if it's not happening according to that schedule, please ensure the service is running. You may want to restart the service. You can also manulaly trigger it too; if you do that, then it will clean up the missing packages right away.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

Hello; this sounds like a NuGet/TFS question, I don't think we'll be able to help much. I would suggest to post to Microsoft forums or stackoverflow.

https://github.com/PowerShell/PowerShellGet/issues/76

An "Access to the path is denied" message is coming from Windows. Permissions aside, a likely culprit is anotherr process (anti virus, backup, etc) is locking the file and preventing access. Sometimes you'll need to use ProcMon to identify what this is. ProGet does not requests locks when reading files.

The only thing that will yield this message -- The process cannot access the file '...' because it is being used by another process. -- is another process having a lock on that file. Windows does not provide information about which process that is. So, you'll need to use a tool like procmon to see file handles, and identify the culprit.

Thanks a lot. It works ;)

Thanks, will try IIS rewrite module for that.(

Hi Ruben, this was a regression in v4.4 after redoing the UI for the combined feed pages. We will fix ASAP in the next maintenance release under [PG-626].

The issue turned out to be a problem with uploading the package to ProGet. ProGet was reporting the package was available in our feed and we were able to download the package through the website however the package was not available through the nuget feed. Deleted and re-uploaded the package a couple times and it finally took. Issue resolved thanks to help from Inedo's great support team! Thanks!

At this time, the NuGet team has no plans to make the v3 API publicly consumable, and will support the v2 API indefinitely as the public API; as such, we have no intention to reverse engineer and attempt to implement a private API. Note this it is entirely a "behind the scenes" transport mechanism (JSON vs XML) and makes no difference at all from a usage perspective.

A FileSystemWatcher is used, so any changes to the directory will trigger an import.