Fog Creek Software
Discussion Board

Final Builder PRO vs. Visual Build Professional?


In the place I'm working at, we're trying to move bit by bit from a "cowboy / macho" I_need-No-cvs development style to something a little more "dull" but (hopefully) more productive. We are past the "get a SCM system" stage, and we'd like to -in gradual stages; we have to keep on developing the products- get some other software engineering "best  practices" on board.

We are looking into doing automated periodic builds. The product itself is hugely complicated (several Platforms - windows 9x, 2000, XP-, server and client components, and a few low level drivers just to make things fun), so making sure everything compiles properly, etc can be a plus.

Up to now there were a few hand-rolled scripts for doing this, but we've started to look into automating (and easing) the process.

From what I've been able to read here, the two "contenders" for the place are Visual Build Pro and Final Builder. I've shown Visual Build Pro to the lead developer today, and he seems to like it (love it would be a better term, probably ;) But before comitting ourselves (ie, $pending money),  I'd like to have your input on the strong and weak points of these tools (or any other you care to mention).

We'd also like to integrate it with our  installer generation routines (currently the installers are hand-generated using Installshield), so ideas for a better integration with Installshiled would be more than welcome.

Thanks a lot.

Javier Jarava
Friday, February 21, 2003

What development platform?

Full name: (Required)
Friday, February 21, 2003

MMm.. I should've been more clear :)

- Visual Studio 6 for C and C++ Development (drivers, and client apps)

- Visual Studio .NET for VB development (server and supporting tools)

- VSS for Source code management

- Installshield for installer generation.

Target platforms: from Windows 95 to XP ;)

  THanks a lot, again ;)

Javier Jarava
Friday, February 21, 2003

I’ve been using FinalBuilder for several months.  I bought it primarily because AtoZed was running a special on FinalBuilder through Joel’s site.  After working with it I’m dramatically underwhelmed.  I expected a much better product for all the hype it was getting.

The problems I found were:

1) Variables are only calculated when the run starts, not when the variable is actually used.  This is an issue if you have variable A dependent on B and C (e.g. version numbers), and you change B after the build started. To get A to have the correct value, you have to explicitly set A after EVERY change to B and C.

2) If you call one build script from inside another, they share variables.  Example:
- Build script X sets the ProjectName variable to “WinForm” at the start of the build
- X calls build script Y for a dependent project and sets  (what you think is) its own ProjectName variable to “ClassLib”
- When Y finishes and X continues, X’s ProjectName variable will be “ClassLib”

3) I use a separate directory (based on the version number) for each build; this keeps the “version history” Joel was advocating recently.  Because the path to the VB.NET solution file is dynamic, I can’t set important properties for the solution build step (like build configuration) without using a text editor to manually edit the step.

4) Lots of minor bugs, like the “Build VB.NET” step not failing when the build fails, or variables not being evaluated in the File Name property of “VSS Checkin” steps.

After lots of trial and error I got my build process to work.  However, I ended up calling each build script independently from a DOS batch file.  This pissed me off because here I paid $300 for a product that promised to get rid of batch files!!

I got the impression that this was originally made to build Delphi projects, and VS.NET support was added as an afterthought.  It would explain why critical aspects of the program seem poorly architected to handle the structure of complicated n-tier VS.NET projects.

I’m curious to hear if anyone else ran into these problems and if so how they dealt with them.

Hope that helps Javier.  I haven't used Visual Build in at least 2 years so I couldn't tell you if it's any better.

Joe Paradise
Friday, February 21, 2003

You can try my free and modest perl version (I wouldn't call it 'FinalBuilder' though ..) for Windows.

It doesn't have a GUI (Unethical in the Perl community ...), but it has support for dynamic variable/environment variable expansions and important built-in actions (FTP, EMAIL, ZIP/UNZIP etc).

See for more information.

If you want to use this script and have questions - just drop me an email (

Good luck :-)

Liron Levy
Saturday, February 22, 2003

I found one more product:
We bought FinalBuilder because it has best Delphi support.

Saturday, February 22, 2003

We settled on Visual Build Pro at the last place we worked primarily because we found it easier to use than Final Builder Pro.

1) The UI was a lot more intuitive.

2) The tech support by Kinook Software was exceptional - you can expect a reply within 24 hours on weekdays, and on the next business day on weekends.

3) Strong support for .NET applications.

Nevertheless when building our .NET application, we still had to write several custom programs to modify the .vbproj files to include specific files, modify certain settings (changing .exe to .dll for example cannot be done automatically).

Visual Build Pro also helped us automate our Doucmentation process. We used Fesersoft's VBXmlComments, NDoc, and FAR. None of these programs were supported build-in but we customized Visual Build to support these programs.

What else? Oh yeah. Kinook provides trial license keys that allow you to go over 60 steps and over 30 days if you need that much time to evaluate the software. I found that to be extremely helpful.

Hope this helps you out. LMK if you need any more feedback.

Saturday, February 22, 2003

As the author of FinalBuilder I'd like to respond to Joe Paradise if I may :

1) I think you are mistaking variables for Macros. FinalBuilder variables are just that, they are set to an initial value at the start of the build and then can be modified during the build.

2) This is as designed, it makes it possible to pass values between the master script and the included script. There is a warning about this in the help file topic for the Include Project action.

3) There is a simple work around for this... keep a master copy to operate on at design time and dynamically set the path to the actual solution file at build time using either variables or script

4) Yes, we have bugs, just like every other bit of software written by humans. None of the bugs you reported were so serious as to make the product unusable.

As for FinalBuilder being written for Delphi, that is simply not true. FinalBuilder was designed and developed as a generic build tool from the start, with initial support for Delphi and VB6, and as time has allowed we have added support for other products such as VS.NET (which was released after FinalBuilder) and Java. All of these additions to FinalBuilder have been made available as free updates. We also provide frequent updates with timely fixes to any bugs reported.

FWIW, we have many users happily using FinalBuilder with VS.NET, they obviously do not find that the product is "poorly architected" as seem to think.


Vincent Parrett
Atozed Software

Vincent Parrett(Atozed Software)
Tuesday, February 25, 2003

I'd put in my vote for FinalBuilder too - i've been using it for a long time now on heaps of projects and it's been awsome; infact "invaluable" would be the word :) 

I did look at VisualBuild but much preferred the flexibilty of FinalBuilder (the excellent scripting support really lets you do just about anything).  The other thing about FB which helped swayed me was the the support for 3rd party products is more complete - AtoZed seem to go out of their way to fully support each product.  HTH, .t8

Tuesday, February 25, 2003

We have produced some VERY VERY complicated scripts with FinalBuilder. The scripts we automated used to take us 1+ days by hand, and often had mistakes during the process. With FinalBuilder our build process is easy and reliable. The biggest script we have consists of over 100 actions.

At most we have ever found is minor bugs and they were fixed very quickly. Compared to our experience with the largest software company in the world (Microsoft) our experience has been very very good. In fact, as I remember many of the bugs were not in FB, but the tools it was calling and FB simply had to make work arounds.

Chad Z. Hower
Tuesday, February 25, 2003


1) No, I'm not confusing macros and variables.  The scripts I wrote use "project variables".  And they behave as I described.  Variables composed of other variables are not evaluated properly if the sub-variable value is changed during the run.

2) Passing values between scripts is a nice feature.  Having a value NOT modified by another script would also be nice.

3) Keep a master copy?  And if my project file changes substantially, do I have to remember to update this copy?  This "workaround" strikes me as a hack.

4) None of the bugs were serious?  The fact that FB doesn't stop when a VS.NET build fails is very serious.  That bug alone cost me several hours when code changes to a support lib weren't compiled as expected.

I'm currently maintaining build scripts for 10 different libraries.  My goal was to define basic steps each VB.NET build script would follow.  Specifics of each project, like the project name or code path, would be abstracted out to variables.  That way, when a new project came along, any script would act as a template for the new script.  Just change a few variables and you're set.  This is possible with FinalBuilder, but I had to do A LOT of work to make sure the variables (especially compound ones) were correct and weren't changed when I ran a dependent script.  Just my experiences with the product, YMMV.

Joe Paradise
Saturday, March 1, 2003

*  Recent Topics

*  Fog Creek Home