This could be caused by a dropped named-pipes connection between the web application and the BuildMaster service. Can you try restarting the BuildMaster service to see if that re-initiates the connection? You can also try running the service interactively to diagnose (http://inedo.com/support/kb/1015/running-the-buildmaster-services-interactively). Also, it could be a server initialization error that happens before anything gets run - make sure you're looking at the Execution Details page for errors related to that instead of the "in-progress" page.

We don't have any plans for this at this time.

Regarding the first error – that sort of thing should only happen if the connector returns invalid data. What is the URL of the bower connector? For the registration, it looks like it’s just an HTTP 401. See this article for info about Bower & authentication in ProGet: http://inedo.com/support/kb/1095/introducing-bower-support-for-proget

i will try to submit this to avira. maybe it would be nice to report it to them too since it is your product that gets blocked! this could lead to misunderstandings.

Thanks a lot! That was exactly the port that was set (and I was probably notified by the installer, but I couldn't find it afterwards)

Thanks- we'll try to expose these properties in the next release.

Do you have any connector filters? If so, try removing those to see if it works. Also, try using the non-SSL URL, i.e. http://www.nuget.org/api/v2 and see if that works. I would also double-check the proxy configuration if you have one set up. If so, see what the message when “Test Proxy Connection” is clicked.

@Tod,@Calvin I've tested it in 3.5.3 and it works now. Thanks!

I can see how to add named groups, but "Domain Users", "Everyone", "Authentication Users" don't seem to be recognized by the add users window. I think we are just going to use a large organizational group that covers most everyone so true anonymous access isn't needed anymore. Thanks!

Activation invalidates when the MachineUUID (MAC Address + CPU-ID) changes; in some virtual hosts (VM Ware), we've seen the MAC change randomly... but it's a setting that you can control.

Upgrading isn't a practical nor helpful suggestion. I guess I'll be looking elsewhere for a feed server.

Looks great. Thanks!

Just wanted to let everyone know who's affected by this that we have a fix in 3.5.0. It's officially classified as a beta version, but only due to some database schema changes. The release notes and download links are here: http://inedo.com/proget/versions

Thank you for the kind words, PJ. No, LOCAL SYSTEM is not a requirement at all, and obviously not recommended for most installations (which is why it is not the default). If you had followed the instructions in the error message that you received, you would know that you could grant the user account hosting the web application the specific ability to control the service by selecting the AllowServiceControl menu option when running bmservice.exe. I've also gone ahead and censored the email address that was entered into the public-facing "Name" field to prevent spam bots from scraping it.

I like the web page solution better than my SQL solution. :) Let's go with that.

The installed express database by default is at localhost\PROGET (i.e. machine_name\instance_name). To switch, simply backup and restore the database into the new instance, and update the connection string in web_appSettings.config under the web installation path, and ProGet.Service.exe.config under the service install path.

yes I am in the right instance (we have only one proget) so we found out our proget had some issues with the db and can't show all package in the ui now we delete from proget and reinstall everything and reindexing all packages I think this will work

Ok thanks for the Info

hallo farhan, wurden Sie TFS? können Sie versuchen, löschen Sie das Verzeichnis "GitRepositories" im build svctmp Ordner? Das sollte das Problem beheben.

This certainly used to work. It looks like nothing has changed on our end. I did some quick testing here with the latest NuGet client and can't seem to get it to send credentials with a push no matter what I do. Based on the error message you've pasted above, it looks like you're having the same issue (that message is only displayed if no auth credentials are present). You can double-check that this is happening in Fiddler, of course, but it looks like this is due to a change in behavior of NuGet.exe.