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.

According to https://docs.inedo.com/docs/proget/feeds/other-types the Composer feed type is planned for a maintenance release of ProGet 2024, which is great news! We're currently using Satis for PHP packages alongside ProGet (for NuGet, npm, Python). Working with Satis is a bit cumbersome, that's why we would very much prefer using ProGet for PHP packages, too. Satis downloads the distribution zips for all packages and generates a static site with package metadata and the zips. I guess ProGet will handle Composer feeds in a similar fashion? Feel free to reach out to me via email if you need further feedback or beta testers for the Composer feed type.

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.

This looks like a bug. The service doesn't have a user context, so it can't actually determine overwrite privileges. It must be trying to overwrite a package with one from the drop path - we'll need to determine what should happen/get logged in this case.

Admin_ManageFeeds was really intended to be more of an administrative task - not scoped to an individual feed. However, this doesn't necessarily make sense and there's no reason it needs to work this way. Apparently there was even some confusion here as that particular page does allow it to be scoped to a specific feed as you discovered. We'll change this task to be scopeable in the next maintenance release (3.4.3) and make sure the admin page is accessible.

Determining the latest packages by date published was actually a fairly expensive query, and was temporarily removed, as it was taking very long to load the page on some installations. We'll be adding it back in a future version - probably 3.4.2 depending on how easy it is to optimize.

Excellent, version 3.4.2 installed and download is now pretty much instant! Many thanks for the incredibly quick turnaround.

And also see this post.

I'd just add that if you are consuming the feed using a different client, ProGet does add an additional OData property called IsLocalPackage that will indicate if it was served locally from that instance of ProGet or via a connector.

Thats fixed it - Perfect thanks!