Ok thanks for the Info

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

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.

Nice read, I just passed this onto a friend who was doing some research on that. And he actually bought me lunch as I found it for him smile Thus let me rephrase that Thanks for lunch! bagkeecdckkdedbb

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 -

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 had the same problem, the packages still showed up after deleting the conector. SOLUTION Restart Proget DETAILS I browsed the database and the packages folder for the offending packages and could not find them. The connector was also deleted from the database. Running feed cleanup also did nothing. In short, I could find no evidence of a problem that would persist after a restart, so I restarted the server Proget ran on and after restart it no longer pulled in packages from the deleted remote. I have proget version: Version 3.7.5 (Build 3)

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

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

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

That would be really great, thanks.

Sure, when I experienced the problem I simplified the scenario by creating a very simple hello world package and I got the same problem. I'll send that to you.

No, but this is now something we can add to non-legacy feeds.

Is this a NuGet package you can send to us for testing? If not, a Fiddler trace of Visual Studio trying to access symbols would also be helpful. You can send either to support at inedo.com and we'll try to reproduce this.

If the feed is a legacy feed, then the import folder is not used; instead packages can be added directly to their storage location. Assuming it's not a legacy feed: Is there anything in the ProGet error log or package indexing error log? Both are accessible from the admin page. If there's nothing in there to indicate a problem, I would try running the ProGet service interactively to see if there's any relevant non-error logged. Just stop the service, and run: Proget.Service.exe run By default, it scans the directory every 60 seconds, so you should see some info about it running a DropPathMonitorExecuter every so often.

Here's the current state of this feed type: We did a pretty deep dive into PHP/Composer packages a while back, and our conclusion was that they were very difficult to implement due to the way the tightly integrate with git repositories. However, we did this assessment without any user partners, and we know next to nothing about PHP, so it could be we misunderstood or looked at the wrong things. Maybe not everyone uses the tight git-repository integration? Hard to say. This is why we partner with customers now. Since then, there haven’t been too many requests for it, and we have no idea what the level of interest is for. Please add to QA#2690 if you've got some insight. You're the first person to inquire about it in over two years... but that same document talks about how we partner with users, and I'd encourage you to check out the RPM Thread -- we've got some great user partners in that!

Unfortunately, we do not support changing the UI language at this time; we may consider doing resource strings/files in the future, but there's not a lot of demand for it right now. However, we do have a source code license available, so that might be a fairly easy way to get French language in the needed pages/screens on the admin pages (or at least the navigation).

This should be fixed in ProGet 3.4.5.