We have been testing our software against Visual Studio 2010 RC and I'm very suspicious that a quirk exists in Final Builder. Our source code consists of a combination of managed/unmanaged code and our build architecture is Cruise Control + Final Builder scripts. Our build server was just upgraded to Server 2008 x64, although the following issue occurred on our previous 2003 server too.
Anyhow, we did a lot of testing just building our code through Visual Studio for some time before attempting to make changes to our build server. We finally had everything working perfectly in VS. As soon as we attempted to run our build through Final Builder, we're seeing strange behavior. Here's a quick sampling:
Our build system launces many Final Builder processes. About 10% of the time, the process launched just hangs for an extended period of time. The build itself may have taken 5 minutes but the process doesn't terminate for, say, 60 minutes.
Every now and then, I have seen cases where the Final Builder process seems dead just as soon as it's launched from an existing Final Builder process. If you go to the taskbar to see the title, it will have the "Not Responding" text.
We have had cases where a Final Builder script will execute a .sln file through MSBUILD but, for some reason, some of the libraries never get built. These all seem to be *.vcxproj based projects.
We just pulled down 1950 to yesterday to see if the issues went away. Unfortunately, we're seeing the same things in both 1916 and 1950.
I was originaly thinking that this had to be MSBUILD related issues; however, we have yet to see these issues manifest when building from within VS 2010. I still haven't learned everything about the new architecture but it seems that by replacing VCBUILD with MSBUILD you can now get the same experience when building from Visual Studio vs. MSBUILD.
It’s quite likely that a quirk exists in FinalBuilder when working with VS.NET 2010 RC. That’s because we really haven’t done much testing with it, and won’t do until VS2010 is released. We have wasted huge amounts of time and resources in the past keeping up with Beta versions of Visual Studio, only to find things changed dramatically with each beta.
The current support is basically the same as it was for VS2008, ie minimal changes were make to get it working, and no testing has been done with unmanaged projects at all. There are several areas in our code where we look at the project files to determine whether it’s managed or not, and in VS2008 and earlier we look at .vcproj files - in 2010 they are vcxproj files which are actually msbuild files. This means at the very least the updating of the Version Info (.rc) is broken, because the vcxproj files are a completely different file format to vcproj, so our parsing code needs updating.
To address your specific points :
1) Need more info. Which FinalBuilder process are you launching, IDE or Console, and how are you launching them, are they using the same FB project file. Why are you launching them, is there a reason you don’t use the “Include Finalbuilder Project” action? 2) Need more info, what settings, command line options, are more than one instance using the same FB project. 3) This is quite a common issue, and is really a VS.NET user error. IF msbuild (which is what the action calls by default) is not building specific projects, then check that those projects actually have a Config that matches the solution Config that you are building.
It’s also possible that our custom MSBuild logger has issues with MSBuild 4. While msbuild is not complaining the output does not look as it does with MSBuild 3.5 and earlier.
We will have full support for the Release version of VS2010. We will release an FB6 update as soon as we have had time to test with the release and fix any issues.
Here is an updated build of FinalBuilder which fixes a couple of issues to do with updating resource files for VC++ builds and logging with Visual Studio 2010 RC.
We use our own mechanism for updating version info in our RC files. I'm not sure if that clears some hurdles but we have not noticed any issues relative to resources or resource files.
With regards to questions asked about launching FB projects, one of our other teams developed the build system that we use. In looking at our 'build driver' system, the main build FB build script is designed to launch other FB instances to do various things. This uses the "Execute Program" task and does not tick the 'Hide Window' option. Although this has been operational now for a few years, I have often wondered why this was done other than this was generally how our older build process worked.
The command line is pretty simple: we pass a bunch of FB variables and then the full path to the 'other' FB script.
With regards to projects not building, I believe we have narrowed this issue down to 'project to project' changes in 2010. I found a recent blog by one of the VC++ guru's at Microsoft and he described the changes in putting more project references in the *.vcxproj files rather than the *.sln files. I had to manually edit a few *.vcxproj files in order to get the proper order (the build dependency order was 100% correct though).
At the moment, I cannot see my original thread but if I didn't mention it, the build process itself via FB is now taking at least 5-6 times longer than via VS. But I think it's getting 'stuck' in certain spots and eventually continues on.
I just pulled down the latest build provided and will give that a go. Also, I realize that VS 2010 RC is not released yet (even though it now has a 'Go Live' label) but like everybody else, it's helpful to flush out the bugs as early as possible.
When you launch the other instances of FB, are you launching FinalBuilder6.exe or FBCMD.exe? Are all these instances sharing the same project FB file? Are you capturing the output of the launched process? Are you running your build from the IDE, if so do you have Live Logging turned on?
Using the Include FinalBuilder Project Action would perform much faster than spawning new processes. Each new instance of FB will have overheads both in startup time and resources (memory, cpu) that are shared when using a single instance and including other projects. Try changing your Execute Program actions to Include actions, that will at least enable you to see where the projects are getting stuck. Another option is to add an export log action to the end of your projects so you can see where the time is going.
Also, I would urge you to send your master project and the child projects to support at finalbuilder dot com so we can take a look and see if we can replicate what you are seeing.