This is by design; accurately paging in the UI is basically impossible due to limited connector aggregation, package filtering policies, etc. Especially after you do a search. Instead, you can display "up to 1000" packages in the UI, which is probably more than you would ever need to scroll through, and search as needed.

I second this. Need to learn Markdown, though

Thank you with version 4.8.12, it's working.

It's a "401" error, which means "not authorized" In this case, you could have the wrong credentials in Yarn (or no credentials). Note that "Windows Integrated Auth" is not supported by npm or yarn.

Good question. Regarding Vor Security, that was a recent acquisition by Sonatype, and it's being transitioned into a new service called OssIndex. Sonatype plans to keep this going for the foreseeable future, and we have verified this with Ken Duck (formerly of Vor Security, now Sonatype employee). ProGet will continue to support it (we are renaming it as well). Moreover, we are planning to work with Sonatype to better integrate their broader services (vulnerability scanning) with ProGet. We are also investigating Blackduck integration, though we're not entirely sure how it would work with ProGet. Regarding "developing our own"... broadly speaking, there are two types of vulnerabilities scanning: static analysis - analyzing actual code or binaries to look for patterns (buffer overflow, etc); this is done "on your own software" repository/database - looking at public databases like NVD, CVE, etc. for vendor- or third-party documented vulnerabilities reported for a known, published piece of software We don't believe that static analysis has a place in a package manger; there are a handful of tools that can scan your codebase directly for this. As for repository/databases, it's not really bout "finding" vulnerabilities in software, it's more about "aggregating databases" and then translating those into machine-readable formats. This is what Sonatype, Whitesource, etc., do, and we think more vendors will continue to innovate in this space. But the "repository" and "scanning" are two different problems, and you should pick the best of both problems; it would almost be like saying "Microsoft makes Office, may as well use Visual Studio and .NET". ProGet has the extensibility support for this already, so we should be able to integrate with new providers as they come up,

Thank you for the followup, that is good information. For future reference, the docs for switching from the built-in webserver to IIS can be found here: https://inedo.com/support/kb/1013/hosting-through-iis-instead-of-the-integrated-web-server The only thing I notice from the article is the mention of Classic mode for the application pool - at some point each product was updated to support Integrated mode.

The Integrated Web Server doesn't have many features, including request logging and tracking. So in this case, you'll want to upgrade to IIS: Please refer to KB#1013: Hosting Through IIS Instead of the Integrated Web Server

Noticed this is already reported https://inedo.com/support/questions/8463

Actually, the API isn't really any faster or slower. If you find it faster to query NuGet.org's "v3" API endpoint, the reason is that it's a static index hosted on a massive Azure server farm. Your ProGet server is considerably less powerful. In addition, ProGet has connectors, authentication, package filtering, etc., and it would never be feasible or useful to generate a static index like NuGet.org does. However, it is on our 2019 roadmap to implement this API, possibly as a new feed type or as an alternate API endpoint for an existing feed. But even so, if you need performance, you may still need likely need to stand up several ProGet servers in a load-balanced manner.

Try stopping the service before running the installer, then it should work.

Hello; thanks for the report, this has been filed as PG-1229

The "remote icon" means that there is a package entry in a remote server. If you're continuing to see it, then it may take a little bit for the connector metadata (in memory)cache to be cleared. You could always stop/start the webservice, and then this will go away.

Please have your colleague follow the instructions in Source and Symbol Serving; it's easy to miss one small detail, and then in this case, it won't work.

You can use the NuGet API for this purpose; https://docs.microsoft.com/en-us/nuget/api/package-publish-resource#delete-a-package Make sure to replace the feedurl with your ProGet Feed's API Endpoint URL (it will start with /nuget, not /feeds)

From what I understand "portable" PDBs were introduced with dotnet core. This is some legacy code that is written in vb.net and is using the full .net framework. As far as I know it is just a traditional windows PDB.

We've been holding to v5.0.6 because it appears this issue is still open and was introduced (as far as we can tell) in 5.0.7: https://inedo.com/support/questions/8240 Has this been addressed in the latest build for linux on docker?

Please share the full stack trace / message under Admin > Message Center.

They fixed an issue using API keys in the latest version 5.0.9 - https://inedo.myjetbrains.com/youtrack/issue/PG-1211

So no version of 5.x is usable when pushing to the feed? I was hoping to leverage v5 because of it's SemVar 2.0 support.

Hello Thomas, I've filed PG-1223 to fix the UI sending you to the wrong URL and promotion trying to load the package from the wrong filename (the name contains the build metadata, but the promotion code doesn't add it on the source feed).