Make sure your feed is configured to cache packages (Admin > Manage Feeds > Edit Properties) and you'll see them in C:\ProgramData\ProGet\Packages\Default\_cache once they've been downloaded/restored: [image: dMRjlvp.png]

Thanks for the report - there is a new version available from the Extension Gallery (v4.1) that should resolve this.

This question was resolved via other means, but the solution would be to upgrade to v4.5+ of the Azure extension.

This is possible using the SDK if you implement a custom package store (to allow ProGet to index packages stored in s3 and to allow it to push packages there), and an OData adapter to alter the package download URL sent back to clients. Our Creating a Custom Package Store tutorial is out of date in terms of the implementation (we are updating much of our tutorials/documentation this week), but there should be enough there to get you started. In short, you'd need to implement PackageStore and ODataAdapterBase. If you need a reference implementation of either, let us know and we can send it to you.

Thanks for the detailed investigation! We have logged this as PG-250 and a fix will be included in the next release (v3.1.7). Provided there's no issues with testing, you can expect this release later today.

IN Database connections, the "Server" field is where the connection will originate from. If your BuildMaster server can talk to database (i.e. has both network access, permission, and drivers), then it's usually simpler to enter the connection string and not worry about installing an agent. It's not a problem to install the agent, it's just not always necessary. Of course, if you need to do other things such as transfer files, then an agent will come in handy.

hi there - you'll want to use the API for this; http://inedo.com/support/documentation/proget/reference/api-methods Note that you can use the SDK if you'd like, and call the API methods via "StoredProcs.METHODNAME.Execute()"

We've fixed the delete issue for the next maintenance release (v4.4.5), and we'll look into adding something to show the applications that consume the workflow - not sure if that will make that version or not.

Sure, we'll add that to the next maintenance release which should be out later today.

Yes, this is a bug. We've been able to reproduce and fix it. The fix will be included in the next BuildMaster release, but if you would like a SQL patch to run sooner, you can email support at inedo.com and we'll send it to you.

We're thinking about it; if NPM proves to be successful and of interest, we would like to branch out to other repositories.

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!