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).

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.

There isn't currently, but there will be soon! Please see PG-1221 I can't imagine any reason at all this wouldn't be done, and it can go it the next maintenance release assuming it passes code review etc! Thanks much for the specific suggestion!

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.

The installer sets it to: SQL_Latin1_General_CP1_CI_AS

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.

The Jenkisn Plugin can only be used to upload Universal Pakages to a Universal Feed. You'll need to use Powershell-Publishmodule command to publish to ProGet.

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

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!

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)

Unfortunately this is a bit tricky to give "general" advice on how to fix, but if you can submit a specific test case that we can reproduce as a ticket, we can research and try to reproduce it,.

Outstanding, thanks Alex

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.

Please check out the ProGet 5.0 Upgrade Notes -- it's got everything in there we're aware of, but please special attention to the bit about NuGet legacy feeds, since there were a lot of questions about it that could have been answered from reading that document.

Both of these package types will be supported in 5.2. PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

Hello Bruce, It looks like this can happen when the package store fails to open the file for writing. If you don't have a custom package store set for the UPack feed, make sure Storage.ProGetPackagesLibrary is set to a full path in /administration/advanced-settings and that the ProGet web server process can modify files in that path.