This can be done as a Promotion Requirement by implementing the PromotionRequirementBase; this class basically just returns a PromotionRequirementStatus that includes a text description and a PromotionRequirementState indicating if the build is eligible for promotion. If you'd like to see how any of the built-in promotion requirements are implemented, feel free to use Reflector or another disassembly tool, or just ask us for the source code for those items.

You can with URL-triggered builds, simply supply the query string argument buildNumber when triggering the URL, and that number will be used instead. For hourly/daily builds or SCM-triggered builds, the only way we could accomplish something similar to this is by modifying the extension to set a build variable.

Do you mean that some symbols are being indexed while others are not?

My bad, MyInedo acc gives that.

I see. Thanks for the feedback - I didn't think about retention but that is a very good point. Retention itself is also a relatively new feature for ProGet, and we are still evaluating whether it ought to be included in the free edition in some form. Regarding feed-specific override paths, we probably will add this in a future release, but I can't give you a specific version as yet.

Hi Wajeeh, It looks like there is definitely something wrong with your database; probably, the stored procedures are being created under different schema (i.e. not dbo). If this is the case, You can rectify this by dropping the database, and then running the bmdbupdate.exe tool from the manual install packages... but it's probably easier to uninstall, drop the BuildMaster database, and then reinstall.

I've read that NuGet's architecture is being redesigned for version 3.0, which should also improve the performance. http://blog.nuget.org/20150608/nuget-server-status.html http://blog.nuget.org/20150601/nuget-3.0-rc2.html

Please see the TFS extension for information on how to do this.

Thanks for your prompt reply. The patch script you linked certainly fixed Issue#4 for us. I think we should be fine to push forward with 4.7.3 as it looks like all the issues have now been resolved. Thanks for linking through that knowledge base article. I'll be sure to have a look through the knowledge base articles before any future upgrades.

Hi Simon, The variable matching isn't taking place because you're using the simple syntax (see "notation" under Variables Documentation). Specifically, BuildMaster is looking for a varaible named "DeployableName_", which doesn't exist, and thus it is replaced as a literal. So, either change to "$DeployableName-$BuildNumber" or "${DeployableName}_${BuildNumber}". Alana

The INEDOPROGETSVC service is used by ProGet to perform background tasks (indexing, cleanup, etc) and is required to run ProGet. The only options (right now anyway) to install the ProGet web application are: IIS-hosted Integrated web server (this is essentially a 2nd Windows service) Linux via Docker (currently v4.0 in beta)

This problem is a pretty big deal - it means that existing TeamCity build artifacts can't be "pulled" into ProGet. The only way to make it work is for new build output, pushing nuget output to ProGet. That's suboptimal.

Integrated, so it uses the account hosting the web application to query.

To find the connector, go to Admin gear > Manage Feeds > Edit Feed (pencil icon), and that will have the list of connectors. For the error itself, try some of these recommendations: http://stackoverflow.com/a/703285

I see 2 boxes left (so around 30)

You can look in the Web.config file in the ProGet Service directory to see what connection string it is currently using to connect to the database. If you installed everything with default settings, this will be using integrated authentication, so it's connecting using whatever account the ProGet Service is running as. Outside of this, whoever installed/updated ProGet last would have also needed to have access for integrated auth.

This isn't currently exposed in the UI, but you can run this SQL query against ProGet's database to get a list of cached packages in a NuGet feed: SELECT * FROM [NuGetPackages_Extended] WHERE [Cached_Indicator] = 'Y' AND [Feed_Name] = 'MyFeedName'

Hi Mark, We just sent you an email with a stop-gap license. Please let us know if you don't get it.

This sounds like a bug in the specification. It was intended to work as you described - keeping 10 for each application, but it looks as if the actual specification is not that clear about it. I'm going to file this as a bug in the software, and we should be able to get it fixed in a maintenance release fairly soon.

Thanks, it works fine now :)