You'll need to run bmdbupdate.exe. It doesn't need to be run on the database server itself; the user that runs it must have dbo permissions to the proget database.

Ah, I see it. I use Caddy as my reverse proxy which doesn't support this feature.

There appears to be a problem with the windows service manager. I recommend you to reboot the server, and try again. If that fails, you can use the manual installation instructions.

Thanks for the response! Gotta say, I'm impressed that y'all take the time to answer questions like this, even when they're from free-license users.

I tried on a different machine which runs Ubuntu 16.04.2 LTS and for some reason I no longer see the problem. Even more surprising is that both machines are virtual machines built from the same VirtualBox image. The 16.04 one was recently upgraded from 14.04. I guess 14.04 image is somehow broken and was fixed during the upgrade. I guess that's answers my question.

I figured that by remove Windows Auth and going back to build-in security but that won't work for my scenario. I've moved to an azure registry and it's working fine. I'm sorry I can't use Proget for all my feeds though. Cheers, ET

Jenkins does not support Windows Integrated auth, so you will need to disable it to get Jenkins to be able to talk to ProGet.

Sorry Sorry Sorry!!! I've tested it on VS2015 and VS2017 and it runs ok!!!! Sorry, 've mismatched the protocol (it must be set to "Atom Feed" (from VSGallery)).

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.