Cached packages are used for downloads only and not metadata. If you need the metadata, you will have to pull the package to ProGet instead of just cache it. Then it will be available even if the connector is unreachable. Note: as of ProGet 3.3 and newer, this is no longer true. Cached packages are now used for metadata queries as well as downloads.

It actually always makes the reservation, though once the service is installed you can immediately remove it with the DeleteReservations command in ProGet.Service. I believe we did this originally to make it easier to switch back and forth between IIS/integrated, but I agree that this should be optional at least, and I will file this as a bug.

How are you creating your application, can you provide an repro steps?

Does this still happen if you add another action after getting the TeamCity artifact? Maybe add a Sleep action with a delay of 5 seconds, just to see if you still get this behavior. I suspect it may be a SQL deadlock issue when an execution completes, but we are still looking into this, and we only have one server we can reproduce this on.

Thanks Tod, that's exactly what I needed. Works like a charm. -Tim

For reference, I have logged this issue as BM-1636, it should likely be included in the v4.4.7 maintenance release.

When you say, "TFS build gets the Source and builds all in one step" ---- do you mean there's a single action (like an MSBuild script) that gets source and builds? If so, then you'll need to make a parameter to this script, and have that update the build/release number with the approraite buildmaster variables.

Well, hmm, I'm not sure how that would happen... unless there's multiple services running? You edit it directly in the database (Servers table); if it flips back, that means something really strange is happening (such as the two services).

This error means that the TFS URL has not been set; you'll need to configure this on the Admin > Extensions > TFS page.

Yes, just inherit from PredicateBase in the SDK. If you don't already have a custom extension, check out the Creating an Auto-Deploying Custom Extension Application tutorial to create one - it will also have a Sample Predicate within it.

We can now support 99% of our clients using the Network Credential Manager. Only one edge case, as discussed with Alex, is still outstanding. We will address that by customising the code in the near future.

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.