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.

It seems the part is causing '1' to be converted to a decimal: https://github.com/Inedo/inedox-windows/blob/88f5924bc1d2397c9edfb135eb9429bbe9fa34e8/Windows/OtterExtension/Operations/PSDscOperation.cs#L241-L243 Of course, because OtterScript is only strings, there's no way to know if it "should" be a string or a decimal. I wonder if the property could be inspected of the dsc resource? I'll note you can shorten @([string[]](1)) to @('1'),

Hmm , it's hard to say. It's just a random crash with no indiciation of a specific error... You should switch to IIS, perhaps then you can get better insight into what might be causing it... or the error might go away altogether.

We're happy to send it, but please make the request via the contact form.

This is not currently a feature, but we could investigate adding it to the extension. I am not an expert in AWS, so can you help us to understand a usecase? Why would you want to use a custom KMS key? How does that benefit vs using built-in? Note it's open source ... https://github.com/Inedo/inedox-aws/tree/master/AWS/InedoExtension/FileSystems

You are correct; once you've enable AD-based authentication, you can authorize groups of users to access ProGet.

I think your best bet is really going to be to use Universal Packages for this. That's what they're designed for, and the operations are much easier to use for it. We very recently updated our documentation to give some guidance on this: https://inedo.com/support/documentation/proget/core-concepts/packages NuGet is designed for .NET library files to be used in developing .NET-based software. Maven is similar, but Java; you should use Maven for packaging up Java code that Java developers will use to build other JAva applications. The applications themselves should be packaged in a universal format.

There's a bug, PG-1211, that will ship in 5.0.9 that should resolve this API Key issue!

Unfortunately it's impossible to say. The error message you have provided is in complete, and doesn't give any information about the problem. Scoped packages works in testing, and we haven't heard issues from othere users about it. You'll need to do some further debugging and provide some more information for us to further help you.