VSoft Technologies Blogs

TFS/VSO Task for Running FinalBuilder Project

Wed, 16 Sep 2015 16:33:00 GMT

Today we are announcing the new build step for Team Foundation Build 2015. This task will allow users of TFS on-prem and VSO to run FinalBuilder projects on Team Foundation Build agents. The task itself is open source and can be found on GitHub.

Those who use TFS on-prem will be very familiar with our XAML build activity already. This activity took a great deal of confusion out of the XAML build process. Changing a build progress from a complex workflow into a simple to maintain FinalBuilder project. The time and effort saved is huge, especially considering the "default" XAML workflow looks like this:

Thankfully Microsoft have improved on their build system with the release of Team Foundation Build 2015. You can read more about this at Team Foundation Build 2015. In summary, the new build system greatly simplifies the build process into a list of tasks to perform.

The FinalBuilder task is our custom task for TFS Build 2015. It offers TFS script builders the ability to still have a simplified overview of their build process while still gaining the power of FinalBuilder and all its supported actions. With FinalBuilder TFS build script creators are able to perform a wide number of tasks that would otherwise require breaking out powershell and diving into the TFS agent environment variables.

When installed, the FinalBuilder Task gives users the following UI. All of the properties present in the UI are easily accessible from within any FinalBuilder script run by the task. FinalBuilder also gives simple access to a list of files that triggered the build.

Installation and Usage

The steps to adding custom build activities to your TFS and VSO instances are quick and easy. We have created a GitHub Repository for explaining how to install, and use our FinalBuilder VSO task.

Repository Clone

To clone this repository use the following command line. You will require git to be installed and available on your path.

> mkdir VSoft
> cd VSoft
> git clone https://github.com/VSoftTechnologies/FinalBuilder-VSO.git
Cloning into 'FinalBuilder-VSO'...
remote: Counting objects: X, done.
remote: Compressing objects: 100% (X/X), done.
remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (X/X), done.
Checking connectivity... done.

With the repository cloned we require the TFS Extensions Command Line Utility (tfx-cli). It comes as a Node Package Manager (npm) package. Npm comes with both the node.js and io.js installer. Download the installer for your Windows platform and run it.

To check that NPM is working correctly you can use the npm version command

> npm -v
2.10.1

Now your able to install the tfx-cli package using npm. Install this globally so that its accessable on the command line. The command line for this is as follows;

> npm install -g tfx-cli
tfx-cli@0.1.11 C:\Users\\AppData\Roaming\npm\node_modules\tfx-cli
├── os-homedir@1.0.1
├── async@1.4.2
├── colors@1.1.2
├── minimist@1.2.0
├── node-uuid@1.4.3
├── q@1.4.1
├── read@1.0.7 (mute-stream@0.0.5)
├── validator@3.43.0
├── shelljs@0.5.3
├── vso-node-api@0.3.4
└── archiver@0.14.4 (buffer-crc32@0.2.5, lazystream@0.1.0, async@0.9.2, readable-stream@1.0.33, tar-stream@1.1.5, glob@4.3.5, lodash@3.2.0, zip-stream@0.5.2)

To test that tfx-cli is working correctly and is on the path use the tfx command.

> tfx
Copyright Microsoft Corporation
tfx  [ ...] [] [--version] [--help] [--json]
                        fTfs
                      fSSSSSSSs
                    fSSSSSSSSSS
     TSSf         fSSSSSSSSSSSS
     SSSSSF     fSSSSSSST SSSSS
     SSfSSSSSsfSSSSSSSt   SSSSS
     SS  tSSSSSSSSSs      SSSSS
     SS   fSSSSSSST       SSSSS
     SS fSSSSSFSSSSSSf    SSSSS
     SSSSSST    FSSSSSSFt SSSSS
     SSSSt        FSSSSSSSSSSSS
                    FSSSSSSSSSS
                       FSSSSSSs
                        FSFs    (TM)
commands:
   build
        manage task extensions and builds
   help
        command help
   login
        login and cache credentials. types: pat (default), basic
        login  [--authtype ] [options]
   parse
        parse json by piping json result from another tfx command
        parse  [options]
   version
        output the version
        version [options]
Options:
   --help    : get help on a command
   --json    : output in json format.  useful for scripting

For tfx-cli to upload a task to TFS it needs to be logged in. We can do this once so that all following commands will use the some credentials. The method used depends on whether your using VSO or an On Prem installation.

On Premises Login

For on premises TFS basic authentication will need to be enabled. The tfx-cli project has a great guide on how to achieve this Using tfx against Team Foundation Server (TFS) 2015 using Basic Authentication.

Once TFS has been configured to use basic authentication use the tfx-cli login command to connect to TFS. You will be prompted for the TFS collection URL to connect to, and the username and password for accessing that collection.

> tfx login --authType basic
Copyright Microsoft Corporation
Enter collection url > https://:/tfs/
Enter username > @
Enter password > 
logged in successfully

With a successful login subsequent commands will not require us to provide the credentials again.

Visual Studio Online (VSO) Login

For VSO login you need a personal access token setup under your account. There is a great article to configure an access token located at Using Personal Access Tokens to access Visual Studio Online.

With the personal access token configured use the tfx-cli login command to connect to VSO. You will be prompted for the TFS collection URL to connect to, and access token for accessing that collection.

> tfx login
Copyright Microsoft Corporation
Enter collection url > https://.visualstudio.com/
Enter personal access token > 
logged in successfully

With a successful login subsequent commands will not require us to provide the credentials again.

Uploading Task

Once logged into TFS we are able to upload the FinalBuilder task to the server. Tasks are uploaded to the server, the server will then pass them onto agents requried to run those tasks.

To upload the task use the tfx-cli tasks upload command. Each command shown below is a sub-command of the previous, so order does matter here. The overwrite option is included so that any previously installed version is overwritten. Note however the highest version number of the task will win when running builds.

Note: This command is run under the directory in which this repositry was cloned to (i.e. FinalBuilderTFS).

> tfx build tasks upload ./FinalBuilder --overwrite
Copyright Microsoft Corporation


task at: ./FinalBuilder uploaded successfully!

To test that the FinalBuilder task is now installed on the builds page for teh collection the task was uploaded to. Create a new empty Team Foundation Build definition. After clicking "Add build step" a FinalBuilder task should appear in the "Build" category.

Further Steps

For more information on the following subjects please follow the links;

How to configure the build task refer to Task UI.
How to install FinalBuilder on an agent refer to Installing FinalBuilder.
How to create a FinalBuilder VSO agent refer to Creating a VSO FinalBuilder Agent.

Team Foundation Server XAML Builds

Tue, 15 Sep 2015 16:16:45 GMT

Team Foundation Server XAML Builds

Today we have released an update for Team Foundation Server XAML activities for FinalBuilder 7 and 8. These updates are to deal with conflicts caused by GAC installing these activities.

Since 2010 Team Foundation Server has allowed custom activities to allow provide extra functionality in XAML build workflows. For those that have not had the (dis)pleasure, XAML workflows can be difficult to work with. To alleviate this pain point we implemented XAML build templates and custom activities to allow people to run any FinalBuilder script within the build workflow without the need to edit XAMAL. Customers we have talked to say this simplifies their TFS XAML build workflows a great deal.

In previous releases, FinalBuilder’s installer automatically installed the TFS XAML activity into the GAC. The version of the activity installed was based on the TFS Agent detected on the machine in question. Installing into the GAC was done to simplify the process. This way the developer would simply use the activities in their build workflow and it would be picked up through the GAC.

With the introduction of the new TFS build in TFS 2015 and TFS-Git in TFS 2013 this is no longer advisable. In the case of TFS-Git Workflows, assembly conflicts can cause assembly load issues. If the activity requires a different assembly version to those already loaded by the TFS agent, you would see assembly load errors with lib2gitsharp. With TFS 2013 having five updates this is increasingly possible .

The way to avoid any assembly loading issue for custom activities is to use “version control paths for custom XAML activities”. To be clear, we have left the GAC installation option in both FinalBuilder 7 and 8. We however do recommend switching to using custom XAML activity paths, especially if you’re using TFS-Git.

To this end, the FinalBuilder installers now give the option as to whether to install the XAML build activities into the GAC or not. Only FinalBuilder 7 will automatically install TFS activities into the GAC for TFS 2012 and earlier agents, with FinalBuilder 8 you much chose whether to GAC install the assemblies.

Note that if activities were previously installed in the GAC restarting the TFS Build Controller is required. This refreshes the build controller and releases any assemblies that it may have previously loaded.

Creating a build definition

The creation of the build definition is exactly the same as before. If you’re interested in how to setup a build definition from scratch using the FinalBuilder XAML templates please review the “FinalBuilder and Team Foundation Server” article.

Custom XAML activities

Version control paths for custom XAML activities is a feature in TFS XAML build controllers. This feature allows the build controller to source all assemblies required for an activity from a known location. If a required assembly is missing from this location the standard .Net assembly lookup methodology is used.

Using version control paths for custom XAML activities requires the activity assemblies to be added to a repository on the TFS system. This repository can be shared with other code, or can be a repository just for the assemblies. As the custom folder does not change based on the build being performed, we suggest a separate TFS repository for the custom activities. The repository can also be either a TFS or Git-TFS repository. Both will work the same.

To add the custom activity assemblies to a repository connect to the repository through team explorer in visual studio.

In the source control view create a new folder that will hold the custom activity assemblies.

In the GAC sub-folder in your FinalBuilder installation (typically “%ProgramFiles(x86)%\FinalBuilder 8\GAC\”) there are folders for each version of TFS custom activities are provided for. From the folder relating the TFS version copy all assemblies contained within into the newly created repository folder.

From the source control explorer add these files to source control.

Updating the XAML Build Controller

Next the build controller needs to be configured use the repository location. In the builds tab of team explorer click on the “Actions” link. A drop down will appear with the option to “Manage Build Controllers…”. Click the “Manage Build Controllers…” menu item.

From the build controllers window that opens select the build controller responsible for the FinalBuilder builds. If there is more than one controller simply follow these steps for each controller. Next click the “Properties” button.

This will present the build properties dialogue in which the “Version control path to custom assemblies” can be set. Select the folder that was created in the repository that is responsible for the custom activity assemblies. Now confirm this change by clicking OK on the build controller properties dialogue.

This has now setup the build controller to source custom assemblies from the configured repository folder. The most recent checked in assemblies will always be sourced. Therefore keeping this repository folder in sync with the custom activities used in build workflows is very important.

Once the custom path is set the build controller can run builds using the custom activities. To test simply queue a build using the FinalBuilder custom activities.

FinalBuilder and Team Foundation Server 2013

Mon, 24 Mar 2014 12:46:18 GMT

FinalBuilder offers you tight integration into TFS with an easy to understand IDE. In this post I will go into how to integrate FinalBuilder into your TFS build process. The post will cover;

Adding a TFS build process
Using FinalBuilder build process templates
Configuration of the FinalBuilder template
Creating a FinalBuilder only build process
Adding running and publishing of tests
Moving files to the drop location

To make sure this post doesn't rival "war and peace" in size, I will assume a few things during the post. Namely that you have used TFS in some fashion, and/or have gotten a solution building under TFS with the default TFS template. For more information on getting up and running with TFS and common issues with TFS I suggest taking a look at the TFS ranger books and blog.

Prerequisites

To follow along with this post you will need the following installed:

Team Foundation Server 2013, with build agent (12.0.21005.1 or later)
FinalBuilder 7 (7.0.0.2745 or later)
Required Visual Studio or MSBuild version available on agent
Agents for Microsoft Visual Studio 2013
Team Explorer 2013

The Team Foundation Server can be of any configuration as long as it has at least one agent and a reporting service. FinalBuilder 7 is required on the agent machine, and could also be installed on the developer’s machine for editing of scripts. Agents for Microsoft Visual Studio 2013 will provide access to VSTest.Console which we require for testing on the build agent. Lastly, Team Explorer is required for interaction with source control from FinalBuilder’s IDE. Without this installed source control will need to be done manually.

Adding a TFS build process

To start I have a solution under source control on a TFS 2013 collection. The solution I will be using is under a team project called VSoftSFTPLibrary under the collection “TFS2013\DefaultCollection”. The layouts of the team project looks like the following:

I have a directory for the SFTP projects source, library files and its tests. The layout of your source control may vary from mine, however the main point to note here is that separating out directories isn’t an issue. With the solution, all related files, and binaries under source control I now add a build definition to the team project.

Next the folders to be used in the FinalBuilder script need to be mapped from the server to an agent location. It’s important to map all folders which contain files required for the build process. At this stage we only really know of the Source directory we are going to be build and the Library folder which the source relies on. Note that if your solution relies on a certain structure of folders this structure should be the same when it arrives on the agent. In the example the source and library paths are at the same folder depth, therefore this is reflected on the agent side.

When the build is finished usually we want them “dropped” somewhere on the network. A FinalBuilder script can use this drop location, which we will go into later on in the artcile. For now I set this to a server location accessible by the build agent service user.

Using FinalBuilder build process templates

By default the build process is set to the default build process which comes with TFS2013. The template is called “TfvcTemplate.12.xaml”. When used the default template will enable the building, testing, impact testing, and deployment of a solution and its projects. Our aim is to perform all the same build activities with the additon of a FinalBuilder project.

To this end, the build process template needs to be changed over to one of the two supplied with FinalBuilder. In the [%ProgramFiles(x86)%\FinalBuilder 7\TFS Templates\2013] folder there are two TFS 2013 build workflow templates. “FinalBuilderTFS2013Build.xaml” performs all the same steps as the default build workflow and adds a FinalBuilder step just after the MSBuild activity and just before the optional “after MSBuild script”. This script is typically used by those looking to convert current default script builds to FinalBuilder in a simple and piece-meal fashion.

The “FinalBuilderOnlyTFS2013Build.xaml” template is used when the FinalBuilder script is to take over the entire build process. For the moment I will use the “FinalBuilderTFS2013Build.xaml” script. Add these two scripts to the team project, typically under a BuildTemplates folder to separate them from the source and library code.

Copy these templates into the local mapped location for this team project, and check them into source control. Now the “FinalBuilderTFS2013Build.xaml” template can be selected as the build process template. To do this add a new new build in the process section of the build definition. Navigate to the source control location where the template is stored and select it.

Configuration of the FinalBuilder template

The next step is to fill in the parameters for the build process. The majority of these are the exact same as the default TFS 2013 template with the addition of some FinalBuilder specific settings. The FinalBuilder section of settings allow for the specification of the project file, and custom arguments for the FinalBuilder project. Note that the “2. Build | Projects”, and the “6. FinalBuilder | Project File” are both required by the build template. These are used to determine what should be built and what FinalBuilder project should be run.

To run a FinalBuilder project we need to create one. Therefore create a FinalBuilder project with just an [Action Group] action for the moment. Save this project to the team projects FinalBuilderScripts folder and check it into source control.

Once the FinalBuilder project is in source control select it in the build process using the file selector provided through the ellipse selector. You should end up with something reading like this “$/VSoftSFTPLibrary/FinalBuilderScripts/BuildVSoftSFTPLibrary.fbp7”

Now that we have included the FinalBuilder project into our build process we need to make sure its folder is mapped to the agent. Open the source settings section, and add a mapping for the folder in which the FinalBuilder project resides. Something like the following should be what results.

Queue the build and the log should read like the following excerpt. The [Action Group] line is the action group you added in the FinalBuilder project.

So now we have a TFS build process which is able to call a FinalBuilder script. In the next section we will delve more into how to extract information from TFS about the build inside our FinalBuilder script.

Retrieving information from TFS in a FinalBuilder Script

For the FinalBuilder script to be of use in the TFS build process, it requires information about the TFS build currently running. To provide this we offer a number of actions that can extract this information during the TFS build run. To get you started, there is an example project in \TFS Templates called TFSExample.fbp7. This sample project contains examples of the actions to use during a TFS build process.

The [Get Team Foundataion Build Parameters] action is a special action that is only useful when a project is launched from TFS. It assigns TFS data to the specified project variables.

Each of the variables in the [Get Team Foundation Build Parameters] action are as follows:

Team Server URL: This is the URL of the team foundation server that queued the build.
Team Project: Is the name of the team project the build belongs to.
Build Id: Is the unique number allocated to this build.
Platform/Flavor: These are the build parameters for the compilation of the solution to be built.
Default Solution File: The solution file listed as the primary for the team project.
Solution File List: The list of solutions to be built by the build process.
Deployment Folder: The drop folder configured for the build process. It is blank if it is not set.
Source Root: The first listed solutions root folder.
Working Directory: A working directory on the agent for the current build definition. Typically space which is shared between builds made on the same agent.

On the Custom Arguments tab is a list of ten variables which can be passed from the TFS build process to FinalBuilder. These are passed as plain text and converted to the variable types used to read them in the FinalBuilder script.

For my script I only wanted to get the Team Foundation Build Parameters, and the variables that it used. So first I checked out the “BuildVSoftSFTPLibrary.fbp7” project using the built in source control features of FinalBuilder.

First I need to make sure that it is indeed added to source control. If it hasn’t detected that it is part of the TFS source control at this stage I add it to source control. I make sure to select the “Microsoft Team Foundation Server MSSCCI provider” which will use the Team Explorer 2013 installed on the machine. I select the TFS 2013 server and collection I am working with, also making sure the team project is correct. Once this is done I am then able to use the file menu to check the project out ready for editing.

Next I copy all the variables I want from the TFSExample project, and paste them into my BuildVSoftSFTPLibrary.fbp7 project. To paste the variables I open the Variables Editor, right click and select paste.

Last I copy over the [Get Team Foundation Build Parameters] and [Trigger Files Iterator] actions. These use the variables we just copied over and will hook themselves up as they appeared in the example project.

Now we can check in these changes and queue the build.

In the log for the build you will see the following:

By default the [Get Team Foundation Build Parameters] action will write what it has retrieved from TFS to the build log. Something to keep in mind when debugging a FinalBuilder script in TFS.

Creating a FinalBuilder Only build process

So now we want to make the FinalBuilder process take over the build completely. The first thing to do here is to stop the TFS build process from building, testing, and publishing results of the build. This requires changing the build workflow to remove the activities which do this (otherwise we would be doing things twice), and updating the FinalBuilder script to perform these tasks.

Instead of working out which activities to remove from the build template we provide a build template with all the build and testing activities removed. The “FinalBuilderOnlyTFS2013Build.xaml” template which was copied into the BuildTemplates folder is this template.

In the process section of the build definition, create a new build process using the “FinalBuilderOnlyTFS2013Build.xaml” file. You will notice that nearly everything in the build parameters is the same except now the before and after script events have been removed. Also the testing section is no longer present. All of this will be handled by the FinalBuilder script.

Once again open your FinalBuilder project for this build and check it out. Also open up the TFSExample.fbp7 project and take a look at the [Build VS.Net Solution] action. Copy this action to the project used to build your solution.

The [Build VS.NET Solution] action builds a Visual Studio.NET solution. On the [Solution] tab you will see that the Solution File is set to “%SourceRoot%\.sln”. Replace with the name of the solution that you wish to build. Note that “%SourceRoot%” will be the directory of only the first solution in the list of projects to build. In my project I ended up with a Solution File value of “%SourceRoot%\VSoftSFTPLibrary.sln” for the [Build VS.NET Solution] action.

On the [Paths] tab you will see that the Output Directory is set to %SourceRoot%\Binaries. You may change this if you wish, but it's it not necessary. Note because the drop location may be on a different server to the build agent, it is important that VSTest runs on files located on the build agent machine. Unless you explicitly set up the trust relationship, .NET will not allow executing of assemblies on remote machines. This is why we build and test in a directory under %SourcesRoot% and then move the files to the drop location after testing. This will be covered more in the next section.

On the agent the TFS agent the FinalBuilder options for Visual Studio will need to be set. If not and DEVENV.COM is required, the build will fail about the build tool location being unknown.

Now we are ready to run the build with using just FinalBuilder. Queue the build again and the project will build, not from a template activity but from the FinalBuilder script it is running.

Adding running and publishing of tests

To perform testing we need to add a [Run VSTest.Console] action to the FinalBuilder project. The [Run VSTest.Console] uses VSTest.Console to run your test assemblies. On the [Settings] tab add the name of your test assembly to the list. You should end up with something along the lines of “%SourceRoot%\Binaries\.dll”. On the [Publish Results] tab the action should be set to automatically publish the results to the TFS server. This means that after the tests are run they will automatically be stored with the build on the TFS Server.

Note that the [Ignore Failure] option, located on the [Options] tab, is important. If any unit tests fail, the [Run VSTest.Console] action will fail, and setting [Ignore Failure] allows the FinalBuilder and TFS builds to continue. Un-check [Ignore Failure] if you would prefer the build to stop on failed tests. In either case, test failures will appear in the TFS build log and in TFS reports.

On the agent the TFS agent the FinalBuilder options for VSTest.Console will need to be set. If not, the build will fail with an error about the VSTest.Console location being unknown.

Moving files to the drop location

The last step to complete the process is to move all the files from the agent to your drop location. The simplest way to achieve this is by a [Move File(s)] action. We already have the drop folder location stored in the %DropShare% variable. It is this value which we then use in the [Move File(s)] action.

Once this is run we will have a built solution, with tests run, and the binaries copied into the specified drop folder.

Team Foundation Build and FinalBuilder

Tue, 02 Dec 2008 03:00:00 GMT

The Accentient Blog provided an interesting post recently comparing Team Foundation Build and FinalBuilder. It was great to see them offer an unbiased insight in to the distinctive advantages of each of these tools and it's worth a read if you're using or planning to use one or both.

We've had plenty to say over the years about the relationship between FinalBuilder and TFS/MSBuild/Team Foundation Build. Naturally, we have a slight bias toward one of the tools, but if you're interested in learning more about combining the two, check out:

why you would use FinalBuilder when you already have Team System;
why FinalBuilder and Team Foundation Build are a match made in heaven;
a comparison between the MSBuild community's wish list and the feature set of FinalBuilder; and

Finally, I must disagree with just one of Accentient's statments. The final line read:

As Team Foundation Build matures, it will likely provide a feature parity competitor to FinalBuilder, but it has some catching up to do.

As Team Foundation Build matures, it may begin to provide feature parity with FinalBuilder 5 or even 6. However, by then we'll be on to FB 7 or FB 8 and we have every intention of making sure these future versions will offer unique and useful features. Team Foundation Build will always have some catching up to do with FinalBuilder.

Top 10 Version Control Systems

Tue, 26 Aug 2008 04:00:00 GMT

Which Version Control System do you currently use?

This year’s results continue to provide an interesting insight into FB user’s version control tool of choice.

Most notably:

Subversion has successfully grown to become number 1 among our customers. This is only a few years after trailing SourceSafe significantly in our 2005 survey.
Despite the efforts of some influential commentators in the developer community (one in particular comes to mind), SourceSafe continues to be a very popular VCS, at least among FinalBuilder customers.
It’s interesting, and quite surprising, to see the number of FB users who choose not to use a version control system. We tend to think of FB users as very savvy developers who seek out tools and technologies to improve their productivity, the type of developers some people generally include in the controversial 20% category. However, a surprisingly large number seem to choose not to use version control. I deliberately say choose, because I imagine every developer using FB is well and truly aware of both the options and benefits of using source control.
TFS hasn’t come close to SourceSafe in adoption among FB users. I may be told I'm comparing apples with oranges, but it doesn't even look like adoption has grown much since 2006.

A few caveats about comparing this year's results with those of previous years. Each year’s survey has a random sample. This year, the VCS question was also worded slightly differently to that used in previous years.

In any case, it’s great to know that FinalBuilder supports all of the top 10 Source Control systems, in addition to many others.

---

This is the 2nd post in a series discussing insights uncovered in the 2008 FinalBuilder survey. Future posts will look at testing tool usage, Vista adoption and the pervasiveness of Continuous Integration.

Hate Team Foundation Server?

Thu, 15 May 2008 01:17:00 GMT

According to Google Analytics statistics for the past month, a number of people found the FinalBuilder web site in Google search results for the query hate "Team Foundation Server"

I didn't know so many people felt that way!

(For the record, we think that FinalBuilder complements Team Foundation Build in very productive ways.)

Team Foundation Build and FinalBuilder 6 (a match made in heaven)

Thu, 13 Mar 2008 18:00:00 GMT

I just posted a new article on Integrating FinalBuilder with Microsoft Team Foundation Server. The article deals with the great new Team Build integration in FinalBuilder 6.

You can now do things with FinalBuilder 6 and Team Build which are impossible to achieve with any other tool combination, and you can do it all without editing any MSBuild files at all.

Need MbUnit test statistics in your Team Build Quality Report? Do it with FinalBuilder.

Need to deploy build results via FTP? Do it with FinalBuilder.

Need to build legacy Visual Studio 2003/Delphi/C++ Builder/VB 6 projects with Team Build, and see compiler metrics in the Team Build Report? Do it with FinalBuilder.

Need smart version information management (including auto-incrementing version numbers across projects) without having to use custom C# code? Do it with FinalBuilder.

Need to do perform any of the thousands of other built-in operations, with full graphical configuration and structured logging output? Do it with FinalBuilder.

If you're interested, check out the new article here.

I also wanted to plug a great (FREE) Screencast creator called Wink, by DebugMode Software. Paul put me onto this and I used it to create the Flash videos in the article. We also have a license to an expensive commercial product, but I don't think I'll ever want to use it again now that I've found Wink.

"I have Microsoft Team System, why do I need FinalBuilder?"

Wed, 07 Nov 2007 03:19:00 GMT

I'm writing this entry from a delegate work area at TechEd Barcelona. We've been talking to a lot of people over the past two days about FinalBuilder.

Many people have said "Oh, we have Team System. We already have automated builds." The surprising thing is how many people don't realise what they're missing out on, or that FinalBuilder can integrate directly with Team System.

With Team System you can do this in your build:

Get a fresh copy of your project's source
Build one or more Visual Studio 2005 solutions
Run Visual Studio tests & Visual Studio code coverage analysis
Deploy built applications to a network share

... that's about it.

Not that this is a bad thing - sometimes all you need to do is to build a solution, and you're done. It's still an automated build, and it's a world better than F5 as a build process.

However, with FinalBuilder you can easily extend Team Build to:

Change the build process without editing XML
Automatically update and increment version information
Build solutions with any version of Visual Studio or MSBuild
Create, edit or remove Work Items based on build outcomes
Deploy to multiple locations, or via FTP
Build third party projects
Build installers
Run tests using different test frameworks
Build multiple versions or editions of the same product
Build legacy code (possibly using different tools)
Retrieve source code from legacy source repositories
Generate structured build logs, with the ability to instantly jump to any points of failure.

FinalBuilder slots directly into Team Build as a build engine, in place of (or beside) MSBuild.

At TechEd, many people have recognised that they face one or more of these scenarios. A few have no other build requirements, but a lot of people have said "Oh, we've been doing that manually" or "Yes, we've been doing this with MSBuild but it's hard and it keeps breaking."

These are the cases where FinalBuilder can help create a true end-to-end build and release system, one which saves time and money and helps safeguard build quality and avoid last-minute surprises.

... and no more XML files!

Mixing up FinalBuilder with Team System (no more XML files!)

Thu, 17 Aug 2006 04:00:00 GMT

One of the comments that we frequently hear from users is "I couldn't do xyz with MSBuild, but I can now with FinalBuilder."

This is great, but hardly surprising. FinalBuilder includes out-of-the-box support for many more tools and processes than MSBuild. Not to mention that it has a GUI to set up your build process - no more editing XML files!

Lately, though, an increasing number of our users are moving to Microsoft Team System. One of the cornerstones of the Team System process is the Team Foundation Build engine, which is built on top of MSBuild.

Now, the Team Foundation Build wizard is fine if you only need to create simple build processes. Get some files, build some solutions, deploy some binaries to a file share. If you need to do anything more, though (and who doesn't?), then you're stuck back in XML land... The same applies if you want to edit your build processes after you've created them.

Plain XML editing, with no built-in support for third-party tools, no support for data processing, no support for parallelisation, FTP transfers, Active Scripting, structured exceptions, recursion or Windows system functionality...

FinalBuilder to the rescue!

The Team Foundation Build engine allows you to add custom MSBuild tasks at any stage of your build process. This means that, with just a couple of lines of XML, you can move your entire Team Build process to FinalBuilder! FinalBuilder can be used in place of MSBuild to provide functionality at every stage of the Team Foundation build process (fetch, compile, test & deploy.) What's more, it all fits perfectly within the Team System framework!

... Happy building!

Version Control Systems

Wed, 18 May 2005 15:01:00 GMT

In our recent FinalBuilder customer survey, one question we asked was “What Version Control System do you currently use, or plan to use in the next 12 months”. The question allowed mulitple answers, so the bars aren't a percentage. I've removed the actual numbers because the relative widths of the bars is what is important.

So, here are the results:

So, interesting results, eh? Obviously Microsoft Team System is high on the agenda for us, and looks like a lot of people will be taking a serious look at the new verison control system.

We'd expect the Subversion bar to continue to grow at a very high rate - last year when we ran a similar survey only 3% of people were using Subversion. SourceGear Vault has also grown a lot, Vault was down the bottom last year, and this year it's really moved up the rankings to just behind CVS. Most of the other VCS's have been pretty steady.

Comments welcome.

Visual Studio 2005 & FinalBuilder

Sun, 27 Jun 2004 15:41:00 GMT

We've been getting an increasing amount of emails enquiring about the future of FinalBuilder since Microsoft announced Visual Studio Team System, and before that MSBuild. It seems we're not the only vendor getting this sort of email, Sourcegear's Eric Sink commented about this in his blog last month and again recently.

MSBuild

MSBuild was first shown last year at PDC in LA, before that I hadn't heard about it. I can tell you that at first I was crestfallen, I could see my business going down the tubes and the prospect of once again looking for a job looming. Fortunately we're still surviving and I haven't had to go out looking for a job yet :)

Since PDC, more information and betas have become available and I've become more comfortable with how msbuild will affect us. I still believe FinalBuilder offers a superior Automated Build Environment which is much easier to use and much more flexible. Sales have improved since PDC, and I think that is in part because developers are more aware of automated builds in general and are looking for something easier to use than manually editing xml files.

In FinalBuilder 2.5 we added an MSBuild Action (along with actions for Ant & NANT), so FinalBuilder already supports building VS 2005 projects (the project files are msbuild files), and of course when VS2005/.NET 2.0 gets closer to release we'll look at tighter integration (it's a moving target at the moment).

Visual Studio Team System

VSTS is a huge product, and from what we've seen so far (TechEd videos and the info on msdn) it looks very exciting, but it won't be for everyone. It's already becoming apparent that the full product won't be included in an MSDN Universal subscription (see the comments by Raju Malhotra) , and my feeling is the server product (Foundation Server, which is required) won't be cheap (apart from also requiring mssql which is itself not cheap). I get the impression that Microsoft are positioning VSTS to compete with IBM/Rational, and to a lesser degree with Borland (who's ALM products like StarTeam & CaliberRM are direct competitors).

Are we happy that Microsoft are now planning to compete with us? Well of course not, but it's no use us crying over it. I do think Microsoft treading a fine line, they need a healthy third party developer tools market, without it the microsoft platform will stagnate and become less attractive (especially if vendors actually get serious about linux). Sadly any hope of a level playing field went out like a damp squid a few years ago...

So what's the future hold for FinalBuilder?

I suspect many developer tools vendors will suffer, and ultimately go out of business (or change their target markets).We don't intend that to let that happen to us however only time will tell.

Our position with FinalBuilder has always been to support as many products (equally well) as we can without an agenda (we don't have a compiler or version control product to push). To this end we already have around 200 actions in FinalBuilder supporting products from many different vendors such as microsoft, borland & java compilers, help generators, version control systems like StarTeam, Perforce, CVS, SourceGear Vault, QVCS, installers like InnoSetup, InstallShield, Wise etc. Many of these products Microsoft will never support themselves. Of course we can't support everything ourselves and we don't have the resources of Microsoft, however we won't shy away from supporting products that compete with Microsoft's.

Work on the next major version of FinalBuilder has already begun, currently we're in the R phase of R&D, but our plans are taking shape quite nicely. We've come up with enough new features to fill several major revisions, over the next few weeks we'll be trimming that down to what we think is the most usefull features and what can realisticaly be achieved with the resources and time that we have, and then we'll be getting stuck into the D phase of R&D. I'm not going to start talking about release dates just yet, far too early for that.

We have also been finishing off FinalBuilder 2.7 which we hope to release this week. FinalBuilder 2.7 includes some nice new flow control type actions to make it even easier than before to create a dynamic build process. FinalBuilder 2.7 is a free update for all registered 2.x users.