All you should need to do is copy the output to wherever you want it published using the "Transfer Files" action immediately following the "Prepare ClickOnce Application".

It does indeed go against the business logic of change control history... and as such we don't have a feature or API call that can "unperform" a change control (or, technically, delete the change control performance record). If you are so inclined, you can delete the relavent row from the ChangeControlPerformances database table in the BuildMaster database... but as with any direct database changes, tread lightly :-)

Check out the BuildMaster API references: http://«host:port»/api/json http://«host:port»/api/soap If you're coding in C#, the SOAP API is probably easier, since it can generate types for you. You'd probably want to call Releases_GetReleases to get a status of all the releases and builds of an application.

We just released our TFS2012 extension - http://inedo.com/buildmaster/extensions/tfs2012

We found that the Change Control feature was somehow disabled when we upgraded the version. Not sure how this happened, but when we set the Change Control setting to (not set) as it was previously, everything was back to normal. Thanks, Matthew

There is no known issue with the layout in Chrome for that version. Chrome likes to cache aggressively (sometimes ignoring the no-cache headers) and will keep things cached even if you hard refresh (w/ CTRL+F5). Try clearing the cache through the menu (CTRL+SHIFT+DEL) and that will probably resolve your issue.

Hi Alex, After reading your (Alex') reply I concluded that given the fact that I'm using a WinXP machine as a build server, using IIS is no option for me. I had already tried the instructions you gave me. I tried them again an to no avail. I did noticed that although I did provide a valid username and password the service was still being registered under the local service user. That was odd. I guessed the settings for the webserver would be stored in the database (as I couldn't find them in the config file). I added the IntegratedWebServer_Prefixes (which I remembered from the settings screen) and added a binding. -> Works like a charm. However, I still wondered why registering the service as described in the knowledgebase article didn't work. So I took a peek inside bmservice.exe. I found the answer in the construcor of the Arguments class. The knowledgebase article is wrong! The command to execute isn't "bmservice /iws /user=[SERVICE_USER] /password=[SERVICE_USER_PASSWORD] /prefixes=[HOST_NAMES]", it's bmservice /iws /user [SERVICE_USER] /password [SERVICE_USER_PASSWORD] /prefixes [HOST_NAMES]". Also, the hostnames aren't sparated by semicolons, but by regular colons. Maybe you could fix this in the knowledgebase? Thanks, // Vincent.

Hi Oleg, The problem is that the database stores some of this information as VARCHAR instead of NVARCHAR. SQL Server converts cyrillic (and other non-Latin) characters to ???. Unfortunately, there is no quick fix; the appropriate columns (and stored procs, etc) must be changed to NVARCHAR. But we do have this planned for 3.2, which isn't too far away. Best, Steve

It appears you've discovered a bug in our variables engine that will be fixed in the next maintenance version v3.1.5 (scheduled on or before 5/25/12). Thanks for the report.

We have a known issue where if you have two test actions with the same group name in the same deployment plan, you will get this error. The workaround is to use a different group name for each test action in the same plan.

Yes; just set up an Source Control Triggered Automatic Build ( http://inedo.com/support/documentation/buildmaster/core-concepts/builds/source-control-triggered-builds ) that watches the desired path(s), and a build will be kicked off when that changes.

Yes. This is what “imported deployables” are used for; on the deployables screen, just add an imported deployable, and then you will be able to create an action group that can deploy that artifact. The “framework recipe” demonstrates this usage somewhat.

This is typically a sign that the account used to install BuildMaster does not have the necessary privileges to create a Windows service.

"Agents" and "Servers" are generally synonymous, but there is a subtle difference. Servers represent actual (physical or virtual) servers that BuildMaster can orchestrate. Actions can operate against Servers, files can be transferred from one Server to another, etc. A "Server Group" is a set of servers that can be treated as a single server. Agents are the mechanism that BuildMaster uses to communicate with servers, and are tied to a specific protocol (SOAP/Binary/SSH) and/or operating system (Windows, Linux, etc). Environments are on a "higher level" than Servers and Server Groups; they describe a stage of testing that your application is currently in, e.g. "Integration", "QA Testing", or "Production". Server groups are a way to simplify deployment to clusters, if necessary. Environments can consist of any number of servers and server groups. To make matters more confusing... you can still work with other servers without an agent, but you're limited to whatever you can do in a normal Windows environment. For example, you can transfer files over UNC paths so long as permissions are set-up, etc. installing an agent and hooking it up to BuildMaster (via External Servers) allows a higher degree of control.

As for the architecture, BuildMaster consists of four main deployable components: Web Application - the primary interface to BuildMaster Service - running aside the web application, the BuildMaster Service is a Windows Service that performs tasks requested through the Web Application Database - a SQL Server database which stores the state and history (you can use your own if you have one) Agent - a light-weight application installed on servers in which BuildMaster can manage and orchestrate Hope that helps.

Yes, as long as BuildMaster supports (see http://inedo.com/buildmaster/integration) the source control provider. It is a best-practice to label your code with a release and build number combination such that it can be retrieved at any point in the future, and more specifically, if you are promoting your code to a further environment. You can set up your BuildMaster action to use the built-in variables %RELNO% and %BLDNO% to accomplish this.

Sure, while you don't have to, BuildMaster is designed to schedule automatic deployments to, for example, an Integration environment immediately upon source control check-in. These plans can run tests, automatically deploy, etc. See our Continuous Integration section on our features page (http://inedo.com/buildmaster/features/continuous-integration) if you would like more information on how BuildMaster works as a CI tool.

BuildMaster is not a build tool in the same sense as make, Rake, Ant, NAnt, etc. However, BuildMaster will integrate with an ever-growing list (http://inedo.com/buildmaster/integration) of build tools to manage your build throughout its release lifecycle by providing an automated deployment mechanism that enhances repeatability, auditing, and maintainability.

First and foremost, it's not a "competing" process, but more of a complimentary one. That is, BuildMaster can be used to automate a RoR deployment via the RAKE action. If you're using db:migrate, this is handled via the RAKE action in the exact same manner. If you'd like to try more advanced database development (as RoR's database support does not use features such as triggers or foreign key constraints), then BuildMaster's change script feature is available for you to try. The primary benefits to doing this are the added dimensions/concepts of applications, releases, builds, promotions, etc. - instead of just files and (possibly) changesets. For small, part-time hobby projects, these benefits are akin to the benefits added by source control and/or issue tracking - just about beneficial enough to use, but not enough to pay for (thus why we have the free edition.)

BuildMaster is licensed to named users who can be managed at any time within the software itself. In our Enterprise Edition we also offer User Classes, which permit only the necessary functions in the BuildMaster software for certain users. For example, your workflow process may require that managers sign-off on a build before it is promoted to the Production environment. The only operation the manager will ever perform in BuildMaster is that approval; therefore, you may purchase an "Approval Only" license at significantly reduced cost for this user.