Thanks for the bug report; this is fixed in v4.5.1, which was just released.

Just use the API/Feed endpoint that you would otherwise use for that feed type as a connector.

If I use this string it returns me: System.ArgumentException: 'server' is not a connection attribute valid. What should I use instead?

Is there anything listed on the Administration > Error Log page that relates to this? Errors listed there will have additional context (feed, connector, etc) If it doesn't appear there, I guess you could enable 1 at a time to see which one is the culprit.

This is by design. The "Packages" listing page (/packages) lists the packages (and all the versions) stored on the local server, across all feeds. The "Feed" page (/feeds/FeedName) will show the aggregated view of packages on the local and remote servers, collapsing all the various versions into a single version.

In Chocolatey v0.10.1, we will automatically switch to using better TLS versions when available. This was done in https://github.com/chocolatey/choco/issues/458. If you see this issue when you are attempting to install Chocolatey itself, please see this documentation to understand your options: https://github.com/chocolatey/choco/wiki/Installation#installing-with-restricted-tls

Thanks!! Works like a charm

Dismiss my recent answer It works fine At some point the connector was removed from the feed which explains why nothing got listed even though the connector was fine. I'm really sorry for this! Thanks for the support!

Today it's working fine. So definitely a temporary outage on nuget.org.

There is a bug in 3.7.x that will be fixed in 3.7.4 On the proxy configuration page, can you enter a dummy value into "Exclude URLs" section, e.g. "example.org"?

I'd be interested in this feature as well. We want to use the NPM registry but prevent developers from pulling newer versions that haven't been tested with our software. We'd also like to block on major, minor and patch revisions. Thanks

It seems to be more stable now, or I can at least see the NuGet page on ProGet. Thanks.

I had the same problem, the packages still showed up after deleting the conector. SOLUTION Restart Proget DETAILS I browsed the database and the packages folder for the offending packages and could not find them. The connector was also deleted from the database. Running feed cleanup also did nothing. In short, I could find no evidence of a problem that would persist after a restart, so I restarted the server Proget ran on and after restart it no longer pulled in packages from the deleted remote. I have proget version: Version 3.7.5 (Build 3)

Thanks for the report, I logged this as an issue to further investigate... PG-492

It's unlikely this will be supported. There is no way to identify from metadata a symbol package vs a regular package... you have to open the zip file and see if it contains pdb/src files... which means we'd have to download every version of every package in a remote feed. If Microsoft / NuGet team ever implements a mechanism for identifying , then it's a possibility.

We wanted to include versions in our Connector Filters, but it wasn't really practical. If memory serves correctly, NuGet's ODATA implementation sees version numbers as strings, thus you couldn't do version ranges or anything like that. I think someone on our team submitted an issue to NuGet about this, but as far as I know it's still treated as strings. So, until then, your best bet is to manually craft your feed. One trick someone suggested was to create a feed with a connector to nuget.org and then download packages to a "Allowed NuGet PAckages" feed (no connectors) --- both of which share the same local directory.