While you are able to specify multiple domains and credentials to those domains, you would have to try it and see. It all really depends on your configuration. Fortunately you are able to create your own user directory, and you could probably just simply use code from the Active Directory (new) and modify it to suit your needs.

Could you capture a Fiddler or WireShark trace of the ProGet response? There should be an error message associated with the 400 (either There must be exactly one package., which would indicate a proxy issue or Package validation failed: followed by an error message, although from a quick glance over the source code, I don't see how that could happen for a NuGet package.) Another possible cause is an IIS module, like WebDav, intercepting the request before it gets to ProGet.

I think I got it working. The documentation is really lacking and hard to find. After hours of searching I found https://inedo.com/support/kb/1112/api-keys-in-proget page. First I had to drop anon permissions to "Publish Packages" (I think it may have been off by default). Add a new task (e.g. "Publish to feed") and select the following operations: Add package Overwrite package View feed Grant anon user permissions to the new task Set an API key for the target feed and use the key in my CI/CD pipeline

Hello Tore, I've fixed the 'syntax error at or near "IF"' error for future versions of ProGet on Linux, but that specific change script failing should not cause any problems. If you want to use the new AD user directory, you can add it on /administration/security/manage-directories. I've filed the missing ChunkedUploads_* functions as PG-1142. They are missing from the Linux version of ProGet. I'll check to see if any other functions are missing.

Yes, it's available. You will need to associate the licenses with a "known" license type that is allowed. Many NuGet packages ship with proprietary licenses, or licenses that point to "random" URLS (like GitHub.org/project-name/license.txt) instead of a "known" OSI URL. This is why they are considered "unknown" to ProGet.

It's not currently supported, but we'll consider doing it through the API or CLI at some point.

This is supposed to check every hour. If it's not, sounds like the service's task runner isn't running. Just restart the service, then its should be ok.

Hello Stijn, This issue is caused by a hidden version of the package: https://www.nuget.org/packages/Swashbuckle.AspNetCore/1.0.0--rc1. I've filed this as PG-1146 and will submit a fix for my co-workers to review.

This is the nature of connectors; if npm client asks for "latest" version, then all connectors need to be searched. If you don't want behavior, then you need to remove connectors that have newer versions.

The situation with Azure is a bit confusing; I will put a note in to the docs team that it should support asset storage, but it can not support large/chunked uploads because of the limitations of the blob storage API that Alana mentioned.

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

This would require writing a custom package store. The disk-based package store does not support this. Perhaps consider using Connectors, or something like that

Hi Alana, Thanks its working fine now.

Hello Alana, That does take you out of the flow a bit, as I assume that this would give them access to edit the "Manage Licences" page? I think is a step in the right direction, but I would still think using the Manage Feed flag and adding that as a role to that which allows Assign Licence is a good option as well. Thanks, Luke

The NuGet URL should be http://proget.edlund.dk/nuget/Edlund , not /feeds/

As an alternative choice you can use Powershell for this. Add a 'Windows Powershell' step (be sure to install that Jenkins plugin first): DIR -Recurse -File -Filter "*.nupkg" | @{ & nuget.exe push $_.FullName -Source https://urltoyourproget/nuget/feedname } You will also need to ensure you have the nuget.exe command line executable available to the Jenkins node running. Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

Yes, create a custom task from the Users & Groups > Customize Tasks page that has the Overwrite Packages subtask, and then restrict it at the system level.

It's probably worth mentioning that we also struggle with pushing packages to this Proget instance, unless we allow "Anonymous" access. The error message we see with nuget push is simply Response status code does not indicate success: 403 (Forbidden) It does not seem to make any difference whether we require an API key for pushing packages or not. We have tried the various solutions suggested in this thread, without luck: https://inedo.com/support/questions/2319

Hi Sebastian, You can access all of the DNC packages using the ODATA (v2) protocol API. If you're finding an issue with it, it's totally unrelated to the API protocol. Please submit a different question with specific packages, reproduction steps and we can investigate Cheers, Alana

Both of these are paid services, and your best bet would be to follow the tutorials to see how to configure them. While they both offer similar outcomes, they do so quite differently. We don't have a simple comparison at this time, but if you find more through your research, please do share!