Sorry, this question somehow got marked as resolved, but it doesn't look like you ever got a response. If you'd like, you can email us at support at inedo.com with details about what you are trying to do, and we can try to give you some more specific help/ideas.

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

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.

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.

Hi again. I found that if i Grant AND Deny the Anonymous user "View Only" privilege then everything is fine.

Proget 3.4.4 Visual Studio fetches the PDB correctly to the symbols cache, but then searches for the source with a local path used on our build server. Sources are not downloaded.

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.

This should be fixed in ProGet 3.4.5.

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 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.

Version 3.4.2 works great, thanks!

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

A "cached" package is a package that's stored locally so it doesn't have to be downloaded from the external feed, as opposed to a "local package" which is a package that is actually in the local feed. Packages are cached the first time they are requested from the external feed (whether that's by downloading it in the UI, or by using nuget restore, or downloaded via some other tool). Pulling a package downloads a remote package into the local feed as if you pushed it to the feed yourself, so to speak.

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.

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.

Thats fixed it - Perfect thanks!

It is supported with Active Directory, so you can use your domain credentials with npm, but since as far as I know the npm client does not send Windows authentication information when it makes requests, there is no way to have this happen automatically. It may be possible to fork npm and add this - say using ldapjs, but I'm not aware of any current projects like that.

Hmm, it's not supposed to require outbound internet access. That should only be necessary to grab a license key, but it should make you enter one if it can't pull one from the internet.