Yes, removing the privileges for the anonymous user will force authentication in the feed. You can also set an API key for the feed similar to NuGet.org feeds. For more info, see: http://inedo.com/support/documentation/proget/feeds/api-keys

We were planning to remove the filewatcher entirely in a future version. For now, we have added a UseFileSystemWatcher setting on the Admin->All Settings page. If you set this to False, and then restart the ProGet service, it will not use the watcher at all. Instead, it will check for updated files at the interval in the FeedIndexerThrottle setting (which by default is 60 seconds). Our best guess is that the internal buffer on the filewatcher was overflowing due to the large number of files, causing this strange behavior. Let us know if this helps. v3.1.5 with this workaround has been released.

This might be related to this NuGet bug... http://nuget.codeplex.com/workitem/4109 Which is aparantely fixed now!

No, this is not a known bug... it may be related to your IIS settings, or something else. Regardless, that's a really really really big package!! You should reevaluate how you have packages > 100mb, let alone 1gb! Best practices dictate to keep these as small as possible.

You can do this from the Admin page under "Licensing & Activation". If there is no internet connection once you click "Activate", it will bring up instructions on how to manually activate.

This is a known bug with NuGet Package Explorer. It appends "/api/v2/package" to the URL when it shouldn't. Here is the related issue: http://npe.codeplex.com/workitem/144 The correct behavior is described in the first scenario here.

Once it is deleted from disk, the indexer will remove it from the DB.

Looks like this has been fixed in 3.2.0. Thanks guys!

It may be as simple as your symbol package getting overwritten. There is no actual difference between a NuGet symbol package and a regular package (except for the file name and the presence of pdb files, and the file name is not submitted with the NuGet push command), so ProGet cannot distinguish between a symbol package and a "non" symbol package. Thus, if you push both, whichever one you push last will overwrite the other one. Can you try changing your process to only push the symbol package and see if that fixes it?

LDAPMultipleDomainEnabled needs to be true to see users in a different domain from the one that the server is running on. The privileges for multiple domain enabled will also be different since the domain becomes a part of the username e.g. principal@domain instead of just principal

Of course, it really depends on the size of the server. ~80% of in-house usage comes from requesting known package (id+version), so this is a fairly performant operation and doesn't take much searching. So, one or two servers is usually ok. For very large package stores (100k+), we seem to have hit some interesting file system / FileWatcher limitations; it works, but sometimes the indexer just stops working. We do plan to redesign the package store, but the work around is easy (just restart the indexing service) Please see http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget for more information on LA/HA proget.

Should be a few days away!

Tod, XML Configuration, in fact, is as you suggested, I was only using "MyAssembly" for reference. This is how I have it. <{Company}.ProGetExtensions.FilteredPackageStore Assembly="{Company}ProGetExtensions"> </{Company}.ProGetExtensions.FilteredPackageStore> I tried to start it from command line, same error.

Hi Tod, Restarting the service fixed the issue. I broke a few CI builds, but oh well! Thanks for the help.

The GetUpdates() method is now included in v3.2.1

Running from console asked me for some input, so entered 1 to Run the service, then entered the feed url that I wanted to start. It then found all of the packages and updated the database. However, upon pushing more packages, I found that those packages weren't updated. Once this happened, I remembered that I had to explicitly create a SQL user for the ProGet database (our server team doesn't allow local server accounts to authenticate to SQL but our domain accounts can). Once I edited the ProGet.Service.exe.config file with the correct credentials, it worked as expected. Thanks so much for the help and the very quick responses! Dave

Something like this should work: sealed class FilteredPackageStore : DirectoryPackageStore { private const int PackagesCount = 5; public override Stream Create(string packageId, SemanticVersion packageVersion, bool allowOverwrite) { var packagesToDelete = StoredProcs.Packages_GetPackages(this.FeedId, "Y") .Execute() .Where(p => p.Package_Id.Equals(packageId, StringComparison.OrdinalIgnoreCase)) .OrderByDescending(p => p.Published_Date) .Skip(PackagesCount); foreach (var package in packagesToDelete) this.Delete(package.Package_Id, new SemanticVersion(package.Version_Text)); return base.Create(packageId, packageVersion, allowOverwrite); } }

This error is related to the UploadReadAheadSize value that is configured in IIS. For IIS7+, see: http://www.iis.net/configreference/system.webserver/serverruntime For IIS6, see: http://msdn.microsoft.com/en-us/library/ms525310(v=vs.90).aspx

Got there in the end. Turns out that the proget service wasn't correctly configured. Once I changed this and restarted the service the packages turned up!

Sounds like you basically just made that check list :) There is no "max password attempts" option as the built-in invalid credentials delay mechanism is sufficient to protect against brute-force/guess attacks. Otherwise, SSL and no anonymous is sufficient.