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

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

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

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

Hello Rickard, Both the C# implementation and the Go implementation from https://github.com/Inedo/upack use the system-defined HTTP proxy.

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 [image: wcVxklE3d9yVAAAAABJRU5ErkJggg==]

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.

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)

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.

Alex, thanks. I don't want to update it via DB I am just going to be changing one and wanted to verify everyplace it's used before I made the change.

Unfortunately, no, I was not. I'm in the process of taking a look at ProGet running in containers again, I will test in the near future and let you know. I don't expect it to be working unless something changed with the containers in the last several months.

Outstanding, thanks Alex

It does purge the packages and logs, but the artifact files themselves are only purged by a Purge Artifacts policy. This behavior is a little confusing I think - we may change it for v6 (by adding an option). For now you can work around it by adding a purge artifacts policy too, and either creating it before the other policies (they are run in the order they are first created), or checking the option to "purge orphaned artifacts," since an artifact file would become orphaned if its associated release package has been purged from the database.

Hi Another point of complexity is the use of script and files in the raft. Lets say, you define myraft and a file called myfile in this raft. You make a plan whatever the raft you use and call myfile from myraft Your code will contain something like ....myraft::myfile But if you rename myraft to mynewraft the plan won't change and it will fail at the next run. The only way to handle correctly the raft renaming would be after changing the raft name to parse all the plans and configurations and templates in all the rafts to replace myraft::myfile by mynewraft::myfile. So renaming a raft is not so simple, according my understanding of Otter :-)

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.

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.