If the service is still running, or was restarted and the same pending behavior persists this situation can also indicate that buildmaster's database has run out of disk space.

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.

This is separate issue altogether, but it seems to be related to something locking the working directories that Perforce is trying to use.

There isn't a built-in predicate for this at this time, so you'd need a custom one.

Yes, you can use Linked Action groups for this, or even share the entire deployment plan and use a variable server for the action groups. Then the actions can inherit the server from the parent action group.

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

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.

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

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.

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.

Should be a few days away!

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.