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!

Looks like that's the wrong url; any url that starts with "/feeds" is for the UI only. Pl;ease use the "API Endpoint" URL specified on that same page intead.

The Directory Troubleshooting docs page has more information: https://inedo.com/support/documentation/various/ldap/troubleshooting

I see, so the actual problem is that you don't have the ability to create or manage AD Groups? Yes, that is certainly annoying... You will probably be better off working within your organization to change this policy. It's awfully silly, and totally defeats the purpose of using AD to begin with. That said, we will consider adding a "teams" feature for a future version.