You could look at the event log under Admin > Events and possibly see when/who deleted it, but there's no way to know "why" it was deleted. ProGet will not automatically delete package versions unless you specify that in a retention policy, or if they're removed from disk or database.

Ok, I've found the problem: Docker image manifests have a really complicated way to compute their digest: Parse the manifest as JSON, keeping key order. Remove the "signatures" key of the root object. Re-encode the new root object as JSON, with 3(!) space indents, LF newlines, and no newline at the end. Compute a SHA256 hashsum. The problem was that on Windows, ProGet re-encoded the new root object with CRLF newlines. This is fixed for the next version. (4.7.7)

Please note that this (or any multi-node) installation requires a ProGet Enterprise or ProGet Load Balanced License to be purchased. ProGet Basic and ProGet Free only permit a single server to be used in a single installation. That said, we recommend IIS because it's the easiest to support (by your own network admin team) and has many configuration options. In theory, you could probably use the integrated server. A HA configuration ought to use a SQL Cluster, otherwise you have a single point of failure.

I tried to use the docker API, however I'm having problems accessing it For example, according to the API documentation: GET /v2/<name>/manifests/<reference> Should get the signature, however using this call: curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -X GET -vvv -k https://<host>/<repository>/v2/<image>/manifests/latest Returns not found. What is the correct way to call v2 API from a proget docker repository ? I couldn't find any documentation about it. Thanks Francisco

Please see the ProGet feature comparison. There are no limits to the number of feeds.a

Glad that worked! I created an issue for this; we should get this behavior a little more intuitive in an upcoming maintenance release.

We will have full support for Windows containers in ProGet 4.7.10, which is scheduled for release tomorrow.

OK, I will upgrade to the latest version. It turns out the ProGet service wasn't running. I hadn't even realized it because the Web site and NuGet/NPM feeds were working normally. Starting the service was all that was needed to get those tasks running. Thanks

thanks we managed to find it as nuget was packing the release and debug files over the top of each other for some stupid reason in just the packages generated for this project. no idea why it did not affect any other solution on our build server

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

Thanks for this post id did help me a lot. I did also get the message "Specified from feed '' does not exist." while trying package promotion. This message is missleading as the real issue was the http Client not passing all the content types as the server wanted. I did try with postman and powershell Invoke-WebRequest. Think the server is unecessary strict with handling the requests, but maybe there is a reason for that. Please consider adding a few "HttpClient" example to the documentation in different languages like powershell, java,c#. It would save the customer a lot of time. https://docs.inedo.com/docs/proget/reference/api/package-promotion

Alana, I think it maybe a UTC boom... I will try today to "fiddler" it.

Thank you for this amazing honest answer, Coming from .NET and Nuget, i've been enjoying the struggles of npm and it's evil offspring for a while now, haha All developers swear it's so good, until we need to make builds from their code...

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

Yes, that's precisely what it would be; an ATOM feed for private galleries that you can push extensions to. I think only MyGet supports it now, so we will look to them for how they handle pushing, so it can be consistent. Most of our enterprise customers wanted to create a workflow like they do with NuGet.org, with only certan public packages in the feed, etc. THat is, they didn't have custom extensions, they only wanted to restrict or cache public extensions for their developers.

Just to clarify... the "NuGet v3 API" is intended for internal-use (i.e. only nuget.exe and NuGet VS extension). Microsoft's new position is that they do not intend on making this API public or stable in the foreseeable future, and that they will continue to support the "NuGet v2 API" (which is documented and public) indefinitely. They actually use ProGet to test changes to v2 API. That said, until this position changes, we will not reverse-engineer the v3 protocol. So this means you will need to use nuget.org/api/v2 in your connector, not the v3 url. Both v2 and v3 API work with client tools, both support DotNetCore, etc. If you're finding a issues with DNC projects, then it's likely related to framework monikers or something like that. Please submit a ticket for this with specifics, so we can investigate and patch.

Spectacular - that was exactly what I was hoping. Thank you for taking the time to answer!

It's hard to say, so we'll need to diagnose a bit further. Could you submit a ticket for this, with the following: which packages work? something from a package that doesn't work... package type (NuGet, npm, etc) metadata file (like nuspec, package.json, or entire package is fine) screenshot exhibiting this behavior With this, we can go back-and-forth over email a bit easier.

Auth tokens are now supported for npm feeds; you'll need to create the token as a ProGet API Key. Please see the API & Access Key documentation to learn more. This is an updated answer; earlier the answer mentioned the feature was not supported.

There is a "multi-domain / forest" AD provider. As long as the domains have a trust to eachother, then the users from the other domain will be enumerated and it should "just work". We are considering building a new active directory provider that allows you to explicitly list the domains to query (instead of doing a trust search), but that ended up getting really complex fast, so it's on hold just for a bit...