VSoft Technologies Blogs


VSoft Technologies Blogs - posts about our products and software development.

FinalBuilder: now with NuGet-y goodness

NuGet is a open source package management tool for .NET applications. It allows you to very simply install, create and share reusable assemblies. With the latest release, FinalBuilder now contains a set of actions to help you interact with NuGet as part of your automated build process.


First things first

To get started, you'll need to download nuget.exe from codeplex. Optionally, if you'd like to Push or Delete to nuget.org you will need an APIKey. You can get one by creating an account at nuget.org and going to the My Account page.

Once you have those, in FinalBuilder go to Tools -> Options and under .Net Tools select NuGet. Set the path to the folder where nuget.exe is located and if you have an API Key, add it in as well.


Installing packages

If you use nHibernate, jQuery or any of the 1500 other packages that are available from nuget.org, you can use the NuGet Install action to keep your build process up to date. This is particularly useful if you're using FinalBuilder on a continious integration server such as FinalBuilder Server.

You can install from the default (nuget.org) server or your own custom package feed. Having your CI server pull down the latest version of a third party library is a quick and easy way to see if the latest version has any breaking changes for your codebase. If it does, you can choose to install a specific version until you've modified your code to be compatable with the changes.


Sharing packages

If you develop an open source library for .NET and want people to use it, it makes a lot of sense to have it published on NuGet. And if you use FinalBuilder to build the library, it's pretty simple to add publishing into your build process. Or, if you have a lot of shared internal assemblies and are looking for a better way to distribute them, publishing to an internal NuGet server may make your life a lot easier.

FinalBuilder has 4 actions to help with the publishing process. If you're familiar with using nuget.exe from the command line they should be very familiar.

The Spec action creates a .nuspec file - either with placeholder data or with metadata from a project file (.csproj) or an assembly. The nuspec is an XML file, so after you've created it you can use FinalBuilder's XML actions to easily manipulate it.

The Pack action creates a .nupgk file from your nuspec, ready for deployment. Alternatively, you can create a package directly from a project file. The Pack action lets you choose which project configuration to use (if you're using a csproj), override the version number and use a pattern to exclude files from the package.

Once you have your nupkg, you can use the Push action to publish it to either the default server on nuget.org, or to your custom NuGet server. If you prefer, you can upload but not publish the package. That way you can manually go to the site and press the Go button before anyone will see it.

Lastly there's the Delete action, which removes the package you specify from the server.


Further information

NuGet.org is the place to go any lots more information. Scott Hanselman also has an excellent presentation that covers everything you should need to know (although we disagree with his choice of build automation tools :) )

Over the next few posts, I'm going to try to talk about some of the lesser known features in FinalBuilder, and show some ideas and techniques that I hope will help you improve your FinalBuilder projects.

Wouldn't it be great if a failed action could automatically retry if it fails?

Absolutely, it's a great idea, and its a feature that's been in FinalBuilder for several years. Unfortunately it's not as obvious as it could be, we ran out of screen real estate a few versions back and it got pushed into another dialog (rather than add another tab!)

Note that this feature should really only be used when accessing a resource which might occasionally fail, for example we use this on our SignTool action when codesigning/timestamping the exe's because the timestamp server (Verisign's) sometimes fails to respond. We found if we ran the build again straight away, the timestamp server usually responds just fine, the server availability issue is usually transient and the retry option with a suitable pause resolves this issue nicely. It makes no sense to use this option on a compiler action though, as the result would most likely not change.

I wish I could define local Variables!

In FinalBuilder 7, you can! The Action Group action in FB7 allows you to define local variables. These variables are then available to all child actions of the Action Group action.


How can I capture and process the output of my custom executable?

We get ask this one quite often, so I guess we haven't done a great job of publicising the Output Monitors feature. Output Monitors are available on all actions, and they allow you to process the logged output of the action. A typical example of the use of output monitors might be to fail an action if a particular bit of text is output from the action.


Variable Suggestion (F12)

This is another one of those features that has been there a while but is not well known. I showed this feature to some of the newer developers here last week and got lots of "oh wow, I never knew that" type responses. I have to admit I'd forgotten about it myself until I started looking for ideas for this post! The way it works is that pressing F12 on a text field will drop down a list of suggestions on variable usage. The list is weighted so that variables that replace the most of the original string will list at the top. This is a great help in making sure you don't hard code paths when the project needs to run on another machine.


FinalBuilder has had an NUnit action for some time now, but for DUnit we have always advocated just compiling the unit test executable as a console app using the TextTestRunner, and using the Execute Program action. This has worked fine, however it doesn't provide the same sort of integration into FinalBuilder Server as the NUnit action provides.

FinalBuilder or later includes a new DUnit action. This action is designed to run DUnit test applications that are written as console apps, and use the FinalBuilder.XMLTestRunner.pas file to run the unit tests. This unit produces and xml report file in the same format as NUnit, which means that FinalBuilder already knows how to parse it. Also included in the FinalBuilder\DUnit folder is an XSL stylesheet and a CSS file to transform the xml report file to html (which can be done using the TransformXML action. The FinalBuilder.XMLTestRunner is a combination of the xml test runner and the text test runner. It still writes out to the console (which the action sends to the FinalBuilder log) and it also writes the xml report file.

When the DUnit action is used under FinaBuilder Server 7.x - the DUnit results are shown on the Status page :

and in a separate tab on the Build Log page :

The Passes and Failures can be inspected by clicking on the green or red buttons.

The FinalBuilder\DUnit folder also includes a simple example test application which shows how to structure your test executable to use the FinalBuilder.XMLTestRunner.

FinalBuilder is available here - disclaimer - please note it is a Test build, which means it's a build which contains bug fixes and or new features since the last official update, but has not had the same testing applied to it as an official update build would.

Delphi XE includes Regular Expression support, something that has been requested many times over the years. In this blog post I'll show some basic usage of regular expressions in delphi. I'm assuming you already understand regular expressions and the associated terminology, if not take a look here for some tutorials etc.

The regular expression engine in Delphi XE is PCRE (Perl Compatible Regular Expression). It's a fast and compliant (with generally accepted regex syntax) engine which has been around for many years. Users of earlier versions of delphi can use it with TPerlRegEx, a delphi class wrapper around it.

The XE interface to pcre is a layer of units based on contributions from various people, the pcre api header translations in RegularExpressionsAPI.pas (Florent Ouchet and co), the wrapper class TPerlRegEx (Jan Goyvaerts) in RegularExpressionsCore.pas and the record wrappers on RegularExpressions.pas (myself). This unit is based on code we currently use in FinalBuilder 6 & 7, it's well tested and has proven to be very reliable in our products.

RegularExpressions.pas is what you will use in your code. It's loosely based on the .net regex interfaces.

The main type in RegularExpressions.pas is TRegEx. TRegEx is a record with a bunch of methods and static class methods for matching with regular expressions. The static versions of the methods are provided for convenience, and should only be used for one off matches, if you are matching in a loop or repeating the same search often then you should create an 'instance' of the TRegEx record and use the non static methods.

So lets look at how we might use TRegEx to find some text in a string.

procedure FindSomething(const searchMe : string);
   regexpr : TRegEx;
   match   : TMatch;
   group   : TGroup;
  i           : integer;
// create our regex instance, and we want to do a case insensitive search, in multiline mode

  regexpr := TRegEx.Create('^.*\b(\w+)\b\sworld',[roIgnoreCase,roMultiline]);
  match := regexpr.Match(searchMe);
  if not match.Success then
    WriteLn('No Match Found');

  while match.Success do
    WriteLn('Match : [' + match.Value + ']';
    //group 0 is the entire match, so count will always be at least 1 for a match
    if match.Groups.Count > 1 then
      for i := 1 to match.Groups.Count -1 do
        WriteLn('     Group[' + IntToStr(i) + '] : [' + match.Value + ']';
    match := match.NextMatch;

In the above example, we are trying to extract the word before the "world", and capturing that in a group. The match method will always return a TMatch, even when no match is found, so you should check the Success property of the Match to determine if a match is found. The same applies to Match.NextMatch, this makes it easy to iterate the matches. You could also call TRegEx.Matches, this returns a TMatchCollection which supports enumeration (using the for in construct), e.g :

  matches := regexpr.Matches(searchMe);
  for match in matches do
     if match.success then
     //do stuff with match here

Something to remember when working with groups is that a match's Groups collection always returns the entire match as group 0, so the groups from your expression start at 1. You will notice I don't free any of the TRegEx, TMatch or TGroups, that's because they are Records with methods rather than classes. This keeps memory management simple and helps avoid memory leaks, my original code used interfaces and reference counting but Embarcadero preferred to use records (as they have done with other new stuff introduced in recent releases).

I have created a simple example application which will help in testing regular expressions :

The source to this app can be downloaded from here

We'll expand on this app in the next post

Introducing FinalBuilder 7

It's been a long time in the making, but FinalBuilder 7 is almost here. FinalBuilder 7 has been in private beta testing for a few weeks, and today we are opening the beta to existing customers.

If you have an account on our website, and have a license for any version of FinalBuilder then you should have access to the FinalBuilder 7 Beta Forum. If you don't see it, try logging out and in again.

What's new in FinalBuilder 7?


Well, as the saying goes, a picture is worth a thousand words.. so lets take a look :

FinalBuilder 7 sports a new IDE.  The FinalBuilder 7 IDE is capable of opening multiple projects (whereas FB6 only allows 1 at a time). The new IDE includes docking, something that has been requested many times over the years, so you can lay out the IDE to suite your taste. The current theme is modelled on Visual Studio, however by the time FB7 ships we should have an alternative theme available too.

There are many little enhancements and tweaks in the IDE. The most requested feature that we did implement is the renaming of variables. In FB6, when you rename a variable it does not rename references to it in the project. FB7 will attempt to find and rename all references (there may be a few cases we have missed, if you find any let us know).

Core Changes

Unicode Support

FinalBuilder is now compiled with a unicode aware compiler. The native internal string type is UTF16, and we have worked hard to ensure that all actions that work with files respect the original files encoding. This has been a massive endevour, and we are still in the process of testing actions to ensure compliance. The user interface should fully support unicode.  Note that while FinalBuilder may support unicode, many of the tools it calls do not.

Variable Types

In FinalBuilder 6 and earlier, all FinalBuilder variables are implemented as Variants. Those of you who have done some COM programming, or used Visual Basic 6 or earlier, or Delphi might be familiar with Variants. A Variant is a type that can store values of various types. Variants are very useful in many cases, but are not without their problems. For example, if you want to store a string "03" in a variant, you will have to put the double quotes around the 03, otherwise we have no idea it's not a number. To circumvent this problem, in FinalBuilder 7 we allow you to specify the variable type :

When you specify a variable type, that is how the variable will be treated, so for example if you attempt to assign a string value to an integer variable it will fail. Typed variables also allow you to specify a format string, which will be used when the variable is evaluated in an expression. For example, if you have a build number variable, that you always want to use as 4 digits, with zeros padding out the left, setting the format string to %.4d will do this.

Local Variables

In addition to the existing variable scopes (environment, application,user, project) and action list parameters, FinalBuilder 7 includes a local variable scope. The Action Group Action has a new property page that allows you to define the local variables.

These variables are only visible to child actions of the group. Since groups can be nested, this provides the ability to override variables locally, and define variables for temporary use.

Local variables cannot be persisted and cannot be used as environment variables.


New Actions

Of course as with every new release we added a bunch of actions:

- NDepend Action
- Git Actions
- Plastic SCM Actions
- Check If Host Exists Action
- SetupBuilder Actions
- SecureZIP Actions
- Signtool Actions
- Hyper V Actions
- Mercurial Actions
- SSH Actions
- XML Node Exists Action

And many of the existing actions had enhancements to them, support for filesets added to more actions.

What about FinalBuilder Server 7?

The FinalBuilder Server 7 beta will be ready in a day or two. It's currently being used to build FB7 (FB7 is built using FB7 and FB Server 7).

What now

FinalBuilder 7 is feature complete for the 7.0 release, there are still many more features we would like to implement in updates. Right now we are in Test/Bug fix mode, that is all the team are working on. So now it's time for some feedback.. let us know what you think, and more importantly, if you find something that isn't working right then let us know. Please keep all beta bug reports and feeback to the FinalBuilder 7 Beta Forum. If you don't see the Beta forum and you are a customer please contact support at finalbuilder dot com and we'll grant you access.