ProGet does not support this for a variety of reasons, primarily security and support. Some users set-up a reverse proxy and rewrite urls, but we don't recommend it. Instead, please just use a different host name (Proget.mycompany.com) or port (mycompany.com:1000).

This is what Retention Policies are designed for, you can configure them to do this.

Hi Team, Thanks for all your support. I was clearing the temp cache for symbol server. Cleaning up a nuget cache fixes the problem for me. Thanks.

Oh god, worked ! Thanks a lot ! Would be super great if there could be a message or a log that says why the operation ended in a brutal closure of the program ;) Just a last remark: I may be wrong but it looks like you did not generate the "Full installer build" since a long time ago. If you look at the download page (http://inedo.com/proget/versions), event if full and small installer links do not lead to the same endpoint, the download size is the same wherever you click. It looks like the small version is deployed on all the endpoints. Thanks again for your help ;)

The Feed Clean-up task, which is run from the service on a schedule you define in Admin > Tasks, will clean up these. if it's not happening according to that schedule, please ensure the service is running. You may want to restart the service. You can also manulaly trigger it too; if you do that, then it will clean up the missing packages right away.

In this case, you are pointing PRoGet to a SQL Server on a different machine. You will need to either use a different connection string (name/[assword), run proget service/web under a domain account and continue to use integrated auth, or allow connections from that machine in SQL Server (not recommended).

Solution found, wrong app pool user. thks all

Alana- looks like this one is actually on me, the reverse proxy was stopping the single quotes. But, the extra trailing slash is what causes the issue with Packages(), same as it does with the earlier problem. I have it sorted out now.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

I've updated the proget plugin to support pipeline script. It hasn't had a lot of testing (PC died and haven't had a chance to fully rebuilt it yet) but the changes were minimal so should be fine. It's also built against the latest LTS of Jenkins so I hope that won't be an issue for you. I'm also trying to do the same with the BuildMaster plugin but that one is proving to be harder to do and I've had to raise an issue on the Jenkins mailing list.

Thanks for the good news!

A License Key is always required. You can get one from My.Inedo.com. The ProGet Silent Installation guide gives the arguments to the installer; one of the options is to automatically request a key (just set Edition to Express or Trial).

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

Restating the Proget's service fixed the problem! Thank you for your rapid response :) Regards.

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way. It was a discussion related to Jenkins so I may have misunderstood where the change was.

You can just drop your npm packages in the configured drop folder; they need to be valid npm package,s which means <name>-<version>.tgz file format.

Correct; that, and the API key, are what get sent over.