Thanks for the clarification. But then you should disable the ability to add anonymous as a group member and show a corresponding warning. With kind regards Boris Bopp

If that were to happen, then you'd need to follow the instructions here to restore it. Resetting the Default Admin Account If, due to a configuration issue, you find yourself locked out of ProGet, you can reset the built in Admin account to its default password and reset ProGet to use the built in directory by running ProGet.Service.exe and selecting the ResetAdminPassword option.

With remote connector caching enabled (default is enabled), there is almost no reason to pull a package to your feed. The reason the Pull feature is there, for example, is so you can pull down your "approved" packages, then remove the connector which in turn makes that package part of your local feed. Anyway, pulled packages are keyed by ID and version, so if a new version were released, you'd have to pull that. Check out some of the features we have planned on the Road Map which will better handle scenarios for users who pull packages often.

After updating to ProGet 3.8.1 the query http://192.168.216.1:25602/nuget/Packages()/$count?$filter=substringof('TESTTAG',Tags) now works as expected. Fixed by • PG-441 - FIX: substringof OData function arguments should be swapped Thanks.

Please see the Features by Edition page.

We're still working it... currently there are some issues surrounding the .NET 4.5 implementation in the Mono distribution, which we hope to see resolved soon!

Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc. In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements. Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors). You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)

We've finally tracked down what was causing this issue. We had two feeds configured that both had two connectors that connected back to the same ProGet server on different feeds. Turns out that this causes a very high request queue on the ProGet server, which in turn caused timeouts and eventually errors during package restore. I've now created a separate web application in IIS hosting the same ProGet folder but running on a different port and configured those two feeds to connect to the other port. This seems to alleviate the problem for now. Would be nice though if this was supported by ProGet itself. I've seen many artifact repositories that support such a feature where sort of virtualized feeds can be created by combining other feeds.

Most definitely; it's a must-have as we transition from a "private NuGet server" to a "private repository manager". I suppose we should explicitly list it under "New repository formats". I'll add a +1 to our (internal) tracker!

All fixed and I finally realized what I was doing wrong the admin password, need to learn where my uppercase characters go in passwords! Thanks, Jon

Hello. What we noticed is that when we receive this error if we delete the nuget package in the feed and then reload it the problem disappear. We still have a legacy feed. Do you think that info could be relevant?

Thanks for the report; in this case, the correct behavior is to not display the log-in form at all when Integrated Authentication is enabled, and instead give an error page indicating no access. I've logged this PG-435

Ah; well, that would explain it :) Your PDB files contain no links to source files, which VS and ProGet are unable o index/locate them. This means you'll need to adjust your complication process to incluse them. A quick search surfaced this article, which may be of assistance: Correctly Creating Native C++ Release Build PDBs. Please do post an update if you find the issue/setting in your project/build file that prevented this from happening.

Actually, one more comment re: this. It appears that the package ID is synonymous with its name. I thought there was a separate ID value. When I grabbed all packages and versions and tried to serialize in PowerShell, it failed due to the size of the content, so it was good to discover that I can query for the specific package name/ID.

Hi, Same question here: http://inedo.com/support/questions/3738. The git repo itself is worth caching for enterprise needs. Actually our developers checkin in the bower_components directory into their git repos, because of the "fear" that the public git repo is getting unavailable. As I can see, https://www.npmjs.com/package/private-bower has this feature. Regards Marco

If you don't specify the symbols option, but include everything in a src directory, then it will work. Keep in mind a NuGet package is just a zip file, so if you're having trouble using nuget.exe with nuspec files and native packages, then you might find it easier to workaround by creating the zip file. Just remember to follow the conventions.

Well, the NuGet API version is totally unrelated; and regarding the v3 API, it's still not stable/public yet, but they are planning a stable/public API at some point in the future (no ETA). Regarding SemVer v2 support for NuGet packages/feeds, tut The NuGet team reports they may support it in v3.5 or v3.6; if/when that happens, we'll add support for it in ProGet's NuGet feed.

We do same in our company. I download Proget from here http://inedo.com/proget/versions and the free verion option is available.

This sounds like it's an issue with your workstation communicating with the server; the 400 indicates a problem with WIndows/NTLM authentication. That's not done by ProGet, but it's handled by IIS/Windows. It could be a whole lot of things, from system clock being off by a few minutes to domain/security issues. Unfortunately there's not a whole lot we can help with, though i'd suggest to search "Windows Auth not working" while including specific messages you're seeing, and try to narrow down form there. Please share what you find, as someone else might come across the same configuration problem.