Here are the commands/switches that would be run ... https://github.com/Inedo/bmx-nuget/blob/master/CreatePackage.cs#L83]

Hm, anything is possible, but I have seen a custom API endpoint causing problems, and a one without privileges set for an API key. Perhaps you can explore the code a little, to see what might be an issue? It's basically just simple HTTP calls to various URLS using Basic HTTP authentication: https://github.com/Inedo/bmx-jenkins/blob/master/JenkinsClient.cs

Currently, the Git provider only monitors a specific branch + path combination in source control. You can however, set up multiple SCM-triggered builds, each pointing at the desired "release/*" branch.

This error means that ASP.NET is not installed/enabled; it's a setting that's available in the server manager console, role/feature settings. Here is a guide from Microsoft on how to enable this: http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-using-aspnet-35-and-aspnet-45

Sorry about that - we accidentally broke SDK compatibility and will have to release a newer version of BuildMaster (v4.7.5) that will have a shim for that method. As a workaround for v4.7.4, you can call: StoredProcs.Applications_GetApplicationsVisibleToUser("Admin", "", 1) to get apps visible to the Admin user of the built-in directory provider (substitute a domain user name and use directory ID 2 if you're using LDAP). This of course assumes the default setup where "Admin" has privileges to view all applications.

You might be able to get away with this with some git trickery, i.e. you can have a script at the beginning of the deployment plan that lists the remote branches and gets the latest commit time for each one, and writes the branch name out to a file (or something like that). Then you can use the "Set Variable Value from File" action to save that value into a BuildMaster variable, and reference that in the "Get Latest" action. Hope this helps :)

Thanks for the bug report. We've just published v4.3 of the NUnit extension which should resolve this issue.

As of BuildMaster 4.9, many of the restrictions in the express edition have been removed. #####Features Available Only in Enterprise Edition (4.9 and later): Enterprise Support Active Directory / LDAP Integration #####Limitations of Free Edition (4.9 and later): 5 Users 10 Applications 5 Servers The following information is outdated, but remains for users of older versions. #####Features Available Only in Enterprise Edition (4.8 and earlier): Enterprise Support Active Directory / LDAP Integration Automated Promotion Requirements Change Controls Configuration File Templates Database Change Script Deployer Deployable Dependencies Group-based Approvals Multiple Active Builds Scoped Privileges Server Groups/Pools #####Limitations of Free Edition (4.8 and earlier): 5 Users 10 Applications 1 Automatic Build / application 1 Configuration Files / deployable 1 Database Connection / environment & application 3 Deployables / application 1 Workflow / application 3 Environments 1 Imported Deployable / application 2 Issue Trackers 5 Servers 3 Source Control Providers

I tried that. Actually, the stop/start link started showing after I restarted the app pool and website. Please, keep me in touch for a solution. Thanks

It goes back to Day 1 of your install; you can query the table directly (it's [EventOccurences]) if you need to do some complex searching.

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.

Just letting you know that we have added a feature to BuildMaster 4.8 that we're calling Ambient Script Variables that should solve this problem. Basically, it allows you do define script variables that BuildMaster will evaluate and assign before running a script. So, in your case you'd just add one called ReleaseNumber that contains the value $ReleaseNumber (the value can evaluate to anything though, and use any variables/functions that are in scope when the script runs). 4.8.0 should be released tomorrow.

My bad, MyInedo acc gives that.

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

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.

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

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.

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.

The self-hosted agent uses a proprietary binary protocol over TCP that is optimized for performance. IIS agents do indeed use SOAP over HTTP (or HTTPS). Both agent types can be secured using SSL encryption and client IP restriction. For an overview of how the agents differ, you might want to check out this article: http://inedo.com/support/kb/1039/comparison-of-buildmaster-agents