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.

The error is "failed with: 401 Unauthorized", so it probably means you need to specify an authentication source? We didn't change the way authentication is handled in v5, so it's likely unrelated to the upgrade.

I'm not too familiar with how OneGet fits into all this; you'd really be better asking this question at the Chocolatey or OneGet forum. You'll still use ProGet to host the packages, but I'm really not sure which client tool (choco, etc) will do the download and install on a desktop.

Hello Josh, I agree that this would be very useful to have. I've filed IEE-8, which will allow the use of variables in block descriptions if the script contains ##AH:EvaluateStatementDescriptions at the top.

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,

This was introduced into 5.8; so please update to the latest v5. https://inedo.com/buildmaster/5.8

I think you are a looking for a different vendor - Inedo's BuildMaster is a DevOps tool, not accounting software.

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. See How to Prevent Server Overload in ProGet to learn more.

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

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

Doubled checked and verified that ASP.NET 4.5 (or later) is already installed.

The behavior your describing is to be expected; basically the API acts as an impersonation token, meaning... if you supply an apikey, and its associated with a user, then it's as if you logged in as that user. So in this case, try this: create a user called ApiUser, and give ApiUser access to myFeed as desired go to the APIKeys and Access Logs screen. create a key and tick Feed API and set Feed API user to ApiUser Assuming myFeed doesn't allow anonymous access (you will need to restrict this from permissions page), then you will need to provide an api key or username/password to access that feed. In this case, just use the key you created. Hope that helps!

It's hard to say, because we don't have enough information. The "code" you shared looks like it's part of a PowerShell script, or maybe it's a cmd script, which maybe they're executing from BuildMaster? Or they could be executing the process directly? Where does $targetInstances and $targetDatabase come from? if they're just running a PowerShell script, then I guess they should just edit that powershell script as you suggested? Can you just ask for the deployment plan? Unless it's v4 or earlier, it will be in OtterScript (a text file), and once you see it, it should be fairly clear how to change it.

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.

That was the first thing I tried to get, though the server sort of hung at the last step, and I couldn't see it right from the installer page. Is there a folder where the logs would have been saved perhaps? They're probably still there if so. I'll be honest. Wasn't so much the server itself hanging as it was a screen reading software I was using to access it.

That doesn't seem right! So, I logged it as a bug BM-3153 We will fix it soon; you may likely be able to work-around it by adding a server by directly going to the URL. In previous versions of Buildmaster, I believe the license would have been disabled.

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.