The feed directory can only contain package files, and remember that a ".symbols.nupkg" is not a valid package file. The ".symbol" file is just a bizarre hack the NuGet team put together to allow you to push half of your package to nuget.org and the other half to symbolsource.org. The nuget.exe client strips the ".symbols" from the name (so the server has no idea what type of file it's receiving). For ProGet, you just have to have everything in a single package... or create a separate feed that the symbol half of your pckage can go to. Basically, you just need to write a script to combine these two files into one. They're just zip files so it should be pretty easy.

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

In this case, it may be best to switch to IIS as the web server to host ProGet. The integrated server is meant more for simplicity and getting started more quickly, and isn't as robust when dealing with these types of network issues. The instructions to do so are here: http://inedo.com/support/kb/1013/hosting-buildmaster-or-proget-through-iis-instead-of-the-integrated-web-server

Thank you for the report. It turns out if the package title is different from the ID, only the title is searched for the list command. We have fixed this on the ProGet end to search both ID and title regardless of difference and are planning on releasing v3.2 today which will include the fix. You could also hack that chocolatey script to use nuget list id:arenaframework-client which should work with the version of ProGet you already have.

When run in parallel, there is no guarantee with the ordering the value is set (and the change would be observed in different groups), so you'd have to create separate variables in each group if you have multiple action groups using different server groups.

Ok, figured it out. The Nuget.exe version I was using was 2.0, I updated to latest (2.8.1) and now I can get versions other than 3.3.0 for NServicebus.Interfaces. Thanks for your help!

The agent does not initiate any traffic back to the BuildMaster server, so no rule needed. The agent installer has the option to auto-register the agent against the BuildMaster server, but that's done under the account of whatever user is installing it, and it only happens once. It's also easy to register a server in BuildMaster too.

Thanks Tod - it seems to have been a problem with our proxy settings but I've got it sorted now.

You would just need to create a second feed, and then copy all of the packages on disk from one to the other.

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.