This has been fixed in v4.4.4

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.

Thank you for your help!

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

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); } }

I can't seem to reproduce this. I've added both an action that simply runs a script and another action that runs a Script Repository script, and both of them write to the output log using write-output. If you're using the "Execution PowerShell Script" action, did you make sure to check the "Log Output" option? Can you export the deployment plan of a simple application that demonstrates this behavior?

Application-level variables take precedence over server variables. Also note the "Legacy variable support" setting under the application's settings, it may be configured to not accept %VAR% as the variable syntax.

At the moment, I'm not able to update our server. I do it later. I will also test with your refernced packages in a test project. Thanks a lot.

@J.D. - can you post this a new question? It may only be tangentially related to the original post in this thread.

Yes, I believe that does make sense. If I want to be able to control order of execution, it sounds like I should turn my deployables into their own separate child applications. Then I can specify order of deployment of each child application within whatever "master" application I am deploying.

Hi Simeon, Windows XP is definitely not going to be a reliable server :) The TCP stack is deliberately throttled/crippled to prevent server usage.

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!

Thank you for the report - I have confirmed this particular page is validating the privilege at the system level instead of the feed level, we'll have it fixed in the next maintenance release.

I installed ProGet 3.1.2 today and the errors I experienced with 3.1.1 are gone. Thanks for the quick turn-around on the fix, you guys are great. Riko

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.

ProGet logs all errors to its error log or indexing errors log in the software itself, otherwise to the Windows event log. You can test by running the service (and/or IIS app pool) as your account if you're certain that your account has enumerate privileges.

An administrator must log in and run the ProGet.Service.exe executable and reserve the URLs you are using, which will also require a system restart before it takes effect.

Does one of your embedded scripts contain a reference to a module that doesn't exist on a remote server, e.g. Web Server Administration for IIS? Unfortunately the error returned by PowerShell is fairly useless in determining which exact module is missing :)