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.

When you say "BuildMaster is not able to see it", are you saying you aren't able to get the latest files in that branch, or that when you browse the branches in the file/folder picker that they aren't visible? I just did a quick test with a Git repository on BitBucket and the moment I added a remote branch, it became visible in the file/folder picker.

We don't have any tutorials for this specifically, but you should be able to build everything using the "Execute Command Line" action: http://help.adobe.com/en_US/Flex/4.0/UsingFlashBuilder/WSbde04e3d3e6474c4-59108b2e1215eb9d5e4-8000.html

I can't reproduce this problem; the query always works for me. Could you send a fiddler trace of the failed request to support at inedo.com?

Strange. If you open the Tools->Options->Debugging dialog in Visual Studio, is the "Require source files to exactly match the original version" item checked? If it is not checked, that may cause it to use an old source file in the debugger. As far as I know, the PDB age is part of the symbol file's unique identifier - when Visual Studio asks for symbols, it makes a request to a URL with the PDB GUID and age. I think age normally gets incremented when a project is rebuilt in Visual Studio, though I don't know the rules about this for sure. Since you get the correct symbols/source if you clear out the symbol directory, I'm guessing Visual Studio just isn't making a request to ProGet because it thinks it already has the correct files. The best thing to do in this case is to run Fiddler and capture a trace of both behaviors and see what's different. You can send us a copy of these to support at inedo.com if you want some help troubleshooting.

It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade. Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.

Yeah that's probably the best bet.

We have fixed this for v4.5.8. For users of v4.5.7, you may download a script patch here: http://44.inedo.com/buildmaster/v4.5.7-JS-Patch.zip This .zip file will contain a JavaScript file that should be saved in the \Resources\jQuery subdirectory of the BuildMaster web application installation. Its presence will override that of the existing DeploymentPlans.Common.js.gz file, and the page should refresh correctly once it's there (you may need to CTRL+F5 the browser once if it doesn't work right away).

Do you by chance have a space (or other reserved character) in the feed name? If so, make sure it is URL encoded when you access it, e.g.: http://domain.com:81/nuget/Feed Name With Spaces