Hey Thanks for the pointer to the nginx fix, works a treat. Here is my docker-compose setup for anyone looking for a quick and great fix... version: '3' services: proget-web: image: inedo/proget:latest ports: - "888:80" hostname: proget-web restart: always volumes: - "/var/proget/extensions:/var.progetextensions" - "/var/proget/packages:/var/proget/packages" depends_on: - proget-postgres expose: - "888" proget-postgres: image: postgres:9.5 restart: always volumes: - "/etc/localtime:/etc/localtime:ro" - "/var/proget/db:/var/lib/postgresql/data" proxy: image: nginx:1.11 ports: - "2345:2345" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro depends_on: - proget-web

Can I stop developers from accessing the Public feed?

That's the error from the SCM, but the .NET error is also logged. You may want to try running the service interactively in this case, then you can see the error message and identify what's wrong with the db connection.

Hello Graham, Filters are what you should use in this case. You can add a package ID like MyCompany.SomeProduct or a wildcard like MyCompany.*. A long list might be hard to work with, since it's just a text box, but if you're only adding new things to the list every so often and not modifying the list all the time, it should be fine.

You can do this... GET /upack/«feed-name»/search?query=«search-query»&count=«max-items» This is the same API that the ProGet Web Application uses to show results to users, and returns a list of packages similar to the packages endpoint.

wow, thank you very much ^^

I understand the frustration... but we really didn't design the UI for quick, rapid package deletes. Have you considered using retention policies instead ? This will automatically purge old versions. You can also write a script that uses the API to do it. As a work-around for the manual mass deleted... I suppose in this case, you could just middle-click to open a new tab, and then delete several tabs at once?

Hello Jim, You can run the ProGet service in interactive mode to see its logs: Stop the ProGet service. In Command Prompt or PowerShell, run .\ProGet.Service.exe run from C:\Program Files\ProGet\Service (or wherever you installed ProGet if you didn't use the default location). It will run the drop path monitor every 60 seconds by default. The message for the drop path monitor starting is Executing DropPathMonitorExecuter.... You can edit Service.DropPathMonitorExecuterThrottle in /administration/advanced-settings to less than 60 seconds if waiting gets too annoying. Immediately after the drop path monitor runs, there should be a message that says Scanning for packages in f:\dsc\droppath. This will be followed by Found f:\dsc\droppath\file.ext any packages it finds. In order to be found, the package files must end in the expected extension: .tgz for npm feeds .nupkg for NuGet feeds .gem for Ruby Gems feeds .upack for Universal feeds .vsix for VSIX feeds If an error occurs while trying to add a package from the drop path, it will appear on a line shortly after the Found f:\dsc\droppath\file.ext line, starting with Error installing package:.

You may have a proxy server that doesn't allow a connection to Inedo.com; that's where latest news is loaded from. There's not enough to help here.

I had the same issue. What seems to solve this is to add "static content" in IIS features link

Assuming ProGet.Service.exe is in C:\Program Files\ProGet\Service, there should be a folder named C:\Program Files\ProGet\WebApp. Does the WebApp folder exist?

Dependency resolution is handled entirely by the NuGet client, so it's hard to say why the NuGet client is hanging like that. There have been no changes to ProGet that would yield this behavior.

Hello Ben, we had a missunderstanding regarding the endpoints. We didn't get that every symbol feed is available at http://proget/symbols and every nuget feed respectively at http://proget/nuget. The naming of our feeds wasn't very helpful with that... Thank you very much.

It's just a way to organize packages. You can filter in the API currently but not in the UI. We had considered that feature when adding universal packages, but so far I believe you are the first to request it :) As an example, we use the groupings for extensions for our products, with the product name being the group for an extension.

Each rule separately checks that all of its conditions are met before deleting a package. If any of the rules decide to delete a package, the package is deleted.

Thanks Alex. Looking forward for new version.

Hi Ben, When trying with the universal feed API endpoint: I'm getting the error: So authorization is ok, but now it seems like feed API is waiting for a Key the extension is not sending.

Hello Jeff, I've fixed PG-1034 and PG-1035 in the next version of ProGet. There is no configuration problem on your server.

Oh, that's certainly a mistake -- actually it came when the feature was released. But I've updated the index page, so it'll be updated at some point when site gets updated. The security API are also unspecc'd. That's something we plan to bring to all products, and will probably be much easier to spec out

Hello Jeff, There is currently a bug in the FeedCleanup task for Docker feeds. PG-1030 has been fixed for the next version of ProGet, but until then, disable the FeedCleanup task for any Docker feeds in /administration/scheduled-tasks.