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.

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 second this. Need to learn Markdown, though

Thank you with version 4.8.12, it's working.

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,

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.

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?

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

Hello Andre, The version number you posted is indeed a valid SemVer2 version number. If you go to the Manage Feed page for the NuGet feed, is there an orange button near the top of the page that says Migrate? If that button is present, the feed is not marked as supporting SemVer2.

Hello Emil, If source or symbol stripping is enabled on the NuGet feed, the package you download will be dynamically created. If you add a query parameter ?includeSymbols=Y in the package request, ProGet will give you the original nupkg file, which should have the SHA512 sum from that field.

See my response here. In summary, it's not a valid SemVer2 version number because it contains 4 parts before the hyphen, and it's not a valid legacy version number because it contains a . after the hyphen.

Hey Ben, I've updated my nuspec: <?xml version="1.0" encoding="utf-8"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> <metadata> <!-- Required elements--> <id>test</id> <version>1.0.0+meta</version> <description>test</description> <authors>tester</authors> <!-- Optional elements --> <!-- ... --> </metadata> <!-- Optional 'files' node --> </package> When I upload a package created from this nuspec, I get this result

This was resolved through a ticket, but the answer I posted there will probably be useful to the general public: LegacyNuGetVersion gets called if SemVer2NuGetVersion is unable to parse the version number. In this case, the version number 1.0.27.14-commit.33ed7ba is neither a valid semantic version (SemVer wants 3 parts before the hyphen, but there are 4) nor a valid legacy version (I believe this is because of the . after commit). For SemVer, something like 1.0.27-build.14.commit.33ed7ba would work. A warning, though: if the commit hash contains only digits 0-9 and the first digit is 0, that is not a valid SemVer either. (spec section 9) A SemVer with a hyphen in it is considered to be a pre-release version, so using 1.0.27-build.14+commit.33ed7ba and then removing the -build.* part for the final version of 1.0.27 would work. If the commit hash is put after a plus sign, it also won't have problems with leading zeroes. (spec section 10)

We use to have a script that auto-unlisted everything. After we switched to the paid version, we found that just using retention rules to clean up pre-release packages after a few days that haven't been downloaded worked a lot better.

If you go to the "Packages" page, you can see packages in ProGet. The feed view will always aggregate your connectors; so if you don't want to see the aggregated (remote) packages, you'll need to disassociate the connectors with the feed.

Hi, Please refer the below blog. You may have an idea on Semantic Versioning. https://www.meritedin.com/robust-api.html Please don't forget to take a look on the videos listed on their playlist.

The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue: https://inedo.myjetbrains.com/youtrack/issue/PG-1203

Hello Phil, This appears to be a bug where NuGet packages with no stable versions keep their first-uploaded version as the "latest". I've filed PG-1201 with a fix. As a workaround, uploading a version of the package with a version number that does not include a hyphen (with a lower version number than the actual latest version of the package) will make the latest version update correctly.

Ok, I see that my issue is exactly what is described in https://inedo.com/support/questions/7450. Thanks for the quick reply. I'll update to v5 when it comes out of beta.