Package promotion is a paid feature; please see Features by Edition.

That works - awesome - thank you so much!

ProGet supports overwriting existing packages, provided the user has such a permission.

Hi @mhull_0872, We just released the latest version of ProGet 5.2.26 on 2/28/2020 which includes the new Package Deployment API. You can learn more about the package deployment tracking feature here. We also have documentation on how to use the API endpoint here. Thanks, Rich

Thanks Alana, [EDO-2856] has been raised. Thanks, Clint

I created a ticket with Paket, and they did resolve the issue via an update to their code base. Testing with version 5.6.6 seems to have fixed the issue. https://github.com/fsprojects/Paket/issues/2466

I think its now implemented: https://inedo.com/proget/versions 5.0.9

Hello Charles, upack pack expects a directory, not an individual file, so the command should be: upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

Release are used to move packages through a specific pipeline, so you can't really have one with out another unless we realllly change our model. Of course in some scenarios, like the one you described, it feels like an unecessary step. We've considered making a simplified "create release/package", where you can do both in one step... but it's deceptively complex to do that on a single page... and have it behave in the same manner. There are permissions to consider, release templates, legacy variables, etc... >.<

Did the multi-part API get implemented for universal packages? This is still an issue.

Version 1.1.0 of the upack command line tool is now available from http://inedo.com/support/documentation/proget/reference/upack. The chocolatey version has been submitted and will be available once it's approved.

I'm on ProGet Version 4.7.8 (Build 4) (locally hosted, not on EC2) and I'm able to upload universal packages to an S3-backed feed using the upack.exe tool with both the latest published release of the Amazon plugin and a debug build from source code. Can you still reproduce the error on the latest version of ProGet?

The npm endpoint to get all packages is /-/all, so in your case: http://dr-tj-pkgsvr01/npm/npm/-/all

Ok, I noticed that in your log, npm isn't authenticating. Is the anonymous user allowed to access the feed in ProGet?

Well, for this, you would use the Download package endpoint There's a lot of guides out there on how to use cUrl (here's a good one), but a basic use would be... curl http://proget.local/upack/my-feed/download/my-group/my-package/1.2.3?contentOnly=zip -o my-package1.2.3.zip ... then you can just use unzip.

If you call $PackageNumber with no arguments, then the curent one in context is returned. The arguments allow you to find a package number for another release in potentially another application.

If this is happening, then the package is not being deleted from the package store on disk and is being re-added by the routine index reconcillation. The most likely cause for this is a misconfiguration (pointing to wrong file store), a file permissions error, or a back-up system restoring the package. When you delete a package, it should be deleted from the database and from the disk.

Thanks for the clarification; I was able to repro this and logged a bug report (BM-2371). It will be addressed in a future maintence release.

Retention policies are available on paid versions of ProGet, so "ProGet Basic" and up; you can see current ProGet Pricing here.

I have experienced what I suspect is the same problem. The package file works if downloaded manually via the website or if downloaded WITHOUT contentonly. If downloaded with contentonly=zip the package is empty. Installing the package via UPack results in an empty package as well. For me, this problem occurs when creating the Universal Package zip file using PowerShell's Create-Archive command. If I use 7-zip or UPack the problem does not occur. This is a bizarre problem and should be addressed as many sysadmins probably reach for PowerShell first. This kind of problem is near rage inducing :)