This is a bug in the free edition; we will resolve it in the next mainteannce release of ProGet.

Are you able to do this from the Admin > All Settings button? There should be a checkbox to enable load balancing. Also, FYI -- as an enterprise customer, don't hesitate to fill out a ticket or email us at support - Inedo - com, and include a couple screenshots or more info so we can better help resolve. This Q&A site tend to get a lower priority, so we may respond slower!

Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

It was most certainly permissions related. From the 4.0 Upgrade Notes... If you modified any of the default roles but did not rename then, then they will renamed to the new task names. In addition, the role's individually-securable actions (formerly, "tasks") will be reset to the new, default definitions

Thanks Alana. Could you guide me to-what table should I be making what changes?

Unfortunately symbols/source can be a little complicated to set up and debug; please review the various resources on the symbols tag, such as the tutorial and questions.

Hi again, My mistake, I selected the latest one and didn't notice that MINUTES before the 4.0.13 version was released and corrects this issue (Mine was 4.0.12 after all). Very, very, very fast guys. Awesome! Thanks!

I'm pretty sure mike you don't need to copy the folders one at a time and wait for pickup...you could copy all the packages at once. And watch out for that powershell script -- it will copy all files in all subdirectories into the current directory, so if your subdirectories contain things other than packages you should add a filter to it.

I think we've identified this and will fix this in the next maintenance; it only impacts the free version, but you can workaround as you've noted.

Update to 4.1.3 has solved this issue for us.

Ah ha! That is indeed the issue. I found the cached files in %localAppData%\Nuget\Cache. Thanks for the quick response!

Awesome ! It works like a charm ! Thanks !

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today. Thanks for the detailed report!

This is by design. The "Packages" listing page (/packages) lists the packages (and all the versions) stored on the local server, across all feeds. The "Feed" page (/feeds/FeedName) will show the aggregated view of packages on the local and remote servers, collapsing all the various versions into a single version.

I understand... you want the ProGet web server to host/serve the icon files themselves... It's very unlikely we will implement an image/file hosting feature. There are plenty of image/file hosting servers out there, or you could just use a basic IIS site to serve files from disk. Note that, on the NuGet roadmap, there is a feature to store icons in the package, like ProGet's universal packages does, using package://myicon.png; this would simplify things quite a bit.

I think I know why, The query shows either targetFramework='unsupported' (for update2 xproj) or targetFramework='DNX451' (for update1 xproj) I think it should use targetFramework='net451'

This has been logged in our issue tracker - it will be fixed in the next release, which will be v4.0.11. We should have that available early next week. It looks like this was just an oversight on our part.

Thanks, this works :)