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.

We don't have a formal EoL policy, but as long as you're current on support (which, just checked, you guys are), we'll do our best to provide support for whatever version you are on. Of course, please understand that, a lot of times, the answer may just be "upgrade to a new version", and we most likely will be unable to provide a hotfix. I suggest you upgrade to v4.6 (we can provide assistance in this as well), and then schedule a routine upgrade/maintenance window (monthly, bi-monthly, etc) so that you can try to keep current. We put a lot of effort into making sure everything is backwards-compatible, and in the event something breaks, you can rollback... or we have the capability to ship a new release within hours.

If you go to Admin->All Settings and change IntegratedAuthenticationEnabled to False and click Save, then it should use forms/basic authentication with LDAP as the user directory source. Note that if you are hosting the web site with IIS, you'll also have to enable Forms authentication and disable Windows authentication in there for the site. If you're using the integrated web server, it should just work. Once configured like this, you can supply the username and password in the url for the client. There is an example of this available if you click on the configuring Bower link visible on the page for any Bower package in ProGet. As far as I know, this is the only way to get it to work.

Under that error message, is a button [Assign Privileges]. So, if you click that button, a dialog will appear that allows you to assign which LDAP users and groups can use ProGet, once you switch to LDAP integration. So, just assign yourself as an administrator.

I believe the publish bug was fixed in the latest npm; you may want to update. Or, maybe it was broken in the latest npm (v2.5.0). In that case, you will want to downgrade. I believe we tested last against v2.2.0. I would also suggest to post this on the npm issue tracker, as will help raise the priority/importance of fixing and maintaining tests to work with repositories other than npmjs.org -

I know this is old but it's still the first thing that comes up in Google when you search for the infinite build issue in BuildMaster. The infinite builds are because applying a label is technically a check-in in DVCSs like Mercurial and Git. So when you apply the label BuildMaster sees a new check-in and starts a new build, which applies a new label, which creates a new check-in, ... I haven't found a good workaround yet.

Just want to confirm that the issue is fixed in ProGet 3.4.7. Thanks!

For me, using the feed name from the URL or getting it in a header makes no difference. So for me, that's not required. Thank you.

I just installed v 3.4.6 Build 6 and it is now working. I used SQL Express installer this time instead of connecting to a stand alone sql server. Not sure if that made any difference.

hey, i just did this on my own install by creating a new feed and adding a deny for the anonymous user for the private feed. hth, marvin

Hi, I was having same issue and finally I managed to get mine working. One thing that helps you identify the issue is this using the Module window in VS: Create a console app and install package Add a break point and Run it in VS Open Module window (Main Menu > Debug > Windows > Module) Find your module and check whether the symbols are loaded (in the status) Right-click on the module and click on Symbols Load Information... Thats the main diagnostics that got mine working, what I also had wrong most likely (not too sure about them tho). I was packing this way: Perform an MSbuild on .sln Invoke nuget pack on .csproj e.g. :> pack proj.csproj -sym Instead I'm doing this now: Make sure the bin (output folder) is cleaned. Invoke nuget pack on .csproj with build. e.g. :> pack proj.csproj -sym -build -Prop Configuration=Release Hope it helps.

In short, only push the .symbols package which contains all of the same files in the standard NuGet package, plus the symbols/source. For more info, see: http://inedo.com/support/questions/1409

Hey Alana, That option sounds fine to me. I certainly think it would cut down the time to spawn up new Applications for us.