TeamCity uses NuGet API v1... which was already deprecated when we build ProGet. So, in this case, you will need to push packages to PRoGet from TeamCity if you want to integrate.

Sure does! See ProGet Silent Installation for more info.

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.

You can add "Auto-promote to next environment" as a Post-Deployment step for your build step, and then the build will automatically be deployed to integration once the build step completes successfully and all promotion requirements are met (i.e. approvals, and automated requirements).

Turns out that a default Win7 install (chosen to keep parity with our dev environment) has power saving enabled. Disabling sleep seems to have solved the problem. I am not a smart man...

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

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?

Generally, load errors are logged to the BuildMaster error log within the software. You could also get live log messages by following this article. Periods in the assembly/file name are allowed, so that must have been unrelated. It's also worth double-checking the extension overview page which will show the load errors, but they don't immediately jump out: [image: EDJnd0T.png] For additional troubleshooting with regard to extension loading: make sure to restart both the BuildMaster Windows service and web application service or IIS application pool once the file is added to the Extensions path make sure there is a BuildMasterAssemblyAttribute specified in the project (normally in AssemblyInfo.cs) the project is targeting the v4.0 or v4.5 version of the .NET framework the file name, the assembly name, and the containing .bmx file all match (i.e. "CustomExtension.dll" should have the assembly name "CustomExtension" and must be contained in the zip file "CustomExtension.bmx")

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

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!