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.

ProGet Basic includes support via tickets submitted at https://my.inedo.com in addition to this QA forum (which is more often community supported) for each year purchased of Annual Licensing. If you choose the Perpetual option, the 1st year is included, and then support may be renewed each following year for 20% of the "then-current" licensing price.

I'm afraid not; it's a generic crash error message. We really need specific ways to reproduce it to help identify what problem is.

Hello Dmitry, I don't think there's currently a way to delete Docker images through the API. The blobs are deleted by the FeedCleanup scheduled task. You can run the task manually from /administration/scheduled-tasks, and it will run automatically once per day by default.

Hello Ben, thanks for help. I can confirm that node.js v 6.11.4 with slash at the end of URL works ;)

There's nothing jumping out in the logs that's off, it likely is bad information that the client is sending. Most likely it's stemming from the fact that, your package is about 100x as big as a NuGet packages (i.e. .NET libraries) are intended to be. Microsoft will probably never prioritize support for this sort of package, so it's not going to be high on our list either to work-around either. I would recommend you to find a different way of solving whatever problem you are trying to solve in a different way. If you're packaging applications, you should consider a format actually built for such purposes, like the Universal Package Format or Romp packages.

Based on that error, it sounds like ASP.NET 4.5 is not enabled on your server; this is a separate role feature you must install on your computer/server. It could also be a configuration error, as the message suggested, and you've prevented proget's web.config from removing those handlers at the machine level. In this case you'll need to use the built-in web server, or fix the configuration.

Hey Alex, Thanks for the follow up! I did continue working on this, and got to a point where I'm happy with how it is working. I was in contact with Karl about it too via email, and sent him some details, but for reference for others who find it useful.. We went with the solution of putting the config into separate files, using the 'configSource' option as needed to specify references to external files. Further to that, we created an extension for Otter to allow us to manage the settings in those files - similar to how the 'EnsureAppSetting' thing works, but allowing an XPath expression to be used to identify the precise element in the config file to check. That meant we could use it for e.g. files that hold connection strings. (I do intend to publish that extension to the Den at some point - haven't so far gotten around to it though). Let me know if you would like any more detail on what we're doing! Thanks, Andrew

Thank you Alana. We have a lot of feeds configured. Is there an easy way to distinguish which one is/are failing?

The docker image is no longer in Beta, FYI.

Can you provide the full stack trace? It will be logged in Admin > Errors.