I have a Persistent project variable with no default value. If I run the project in the console, the variable persists ok through subsequent runs. However, if I run the project via the command line (using an Include action), the variable does not persist - whether it is initially set in the Console or the command line build. Is this a bug or am I doing something wrong?Using FB 5.0.0.84.
Hi Andrew,
This bug should be already fixed, please try this build:
https://www.finalbuilder.com/downloads/finalbuilder/500/FB500_93.exe
cheers,
tate.
I think I'm experiencing this same problem, however I'm running version 5.5.0.518.
Is it reasonable to assume that my build should already contain this fix?
Hi Zack,
That build should contain the fix for the bug described above. Are you seeing the exact same behaviour? Is it possible for you to outline it again for us, please, because the original post is a little confusing about the specifics.
Regards,
Angus
I think its pretty close the behavior described above but I’ll redefine the problem the best I can.
We’re running CruiseControl.NET which invokes our FinalBuilder projects. The Projects have a persistent variable defined that increments every time the build is run. For some reason, this variable is getting either randomly or is failing to increment. Just to give you a little more background, we were running our source control out of VSS for quite a while with this setup and experiencing no issues. A few weeks ago we switched to Fortress (aka Vault) and that seems to be when this problem started to show up. We’re also using Visual Studio 2008 for some of our builds, and these appear to be the most problematic. I’m not sure if VS 2008 support is officially out yet, we obtained a build of FinalBuilder that supported it via these forums.
Let me know if there’s any more info I can provide such as logs, sample projects files, etc.
Thanks!
Hi Zack,
Thanks for the update. 518 is the current official build with 2008 support.
Is there any chance you have the .fbv file checked into source control? That file is where the persistent variables are stored, and if it’s checked in (ie Read Only) then you won’t see any changes saved to it (for obvious reasons.)
If you’re using the built-in SCC integration there is an option called “Keep auxillary files checked out” which will keep them in source control, but keep them checked out after each checkin so they’re always writeable.
Hth.
Regards,
Angus
No we don’t have the files in source control and I’m fairly certain the fbv file is writeable.
Would it be helpful if I emailed you a sample project?
I don’t know if this will help you, but I’m pretty wary of persistent variables in general if the information they contain is important. I lost all the values of my persistent variables once, either due to a FB bug, a mistake on my part or some freak event. In general, I find it better to simply store the variables’ values in a .ini file, and load/save that at the appropriate times - you can load all the variables in just one action. If you version control that file, your chances of losing important values are very slim.
And it makes you feel good to have so much control over how and when the variables get populated with values 
Steve
I thought ini files were supposed to be “read-only”, like a config file. Seems that if persistent values are not truly persistent, or are just persistent when they feel like it, that would be a bug IMO.
The value we’re incrementing in our case is the build number, so its not really something you’d want version controlled, but it is important that its incremented every build and that its saved between builds.
I guess what I’m saying is that if I have to go through some hacky work-around to persist a value when there’s already a prominent feature advertising that it handles all of that for me, I’m thinking that the feature should be fixed.
Thanks
Zack
Hi Zack,
Thanks for your patience with this. You are, of course, correct that persistent variables should work "as advertised."
At the moment, I can confirm there is a bug with persistent variables which have defaults set - the variables are being reset to the default on each build, regardless of the persistent setting. This happens in both the IDE and FBCMD.
So as a temporary workaround, if the variables have default values set then removing them will fix the problem.
We should have a test build with a permanent fix out very soon.
Regards,
Angus
PS FYI, Ini files are designed for reading and writing (the Windows Ini file APIs work for reading and writing.)
Zack,
If this isn't the bug you're seeing, could you please email us your project file (to support at finalbuilder dot com.)?
Thanks.
- Angus
Thanks for the tip Angus, I’ll give’er a go tomorrow and report back.
I think I finally tracked down the issue. First, a little background.
We have 2 builds running, one for Dev and one for QA. When each of them runs they create a label on the source and then pull from that label. The problem was that the QA build was labeling the same as the Dev build, thereby attempting to create duplicate labels and subsequently failing the build. I think that was causing the persistent variables to not be written to the fbv file.
Thanks for the help, apologies for any confusion I may have caused.
Thanks Zack. Glad to hear you got it working. We turned up a bug anyhow, so something positive will come out of your bug report. :).
Hi Zack,
Actually, I can't reproduce that bug at all any more - I think it must have been user error on my part the first time.
Regards,
Angus
Hi, sorry to reopen this long closed thread, but I work with Zack and a similar flavor of this issue is cropping up again. While he figured out what was going on there, now what I’m running into is this:
Running CruiseControl.NET to invoke the FB projects works fine, the build number (persistant variable) increases as designed. But then if I need to update the project, once I open the FBV file up and save it, the variable resets. I know if we remove the default value, this will correct itself, but then the value goes back to 1. The build number is being used as a label in Fortress (aka Vault) and when the project builds, it errors out that the “label already exists”, because the variable has dropped back to either 1 or the default value + 1 depending on if there’s a default value or not.
Our workaround has been to look up what the highest label number is when we need to edit a project and increase the default value to that, but should FB be losing the saved variable increment just by opening the project in the first place?
Hope that makes sense.
Thanks!
Hi Andy,
The variable definitely should not be resetting as a result of just opening and saving the project. Is the .FBV file checked into version control? Under this circumstance it’s possible that the local FBV is being overwritten with an older file from version control. Unfortunately the SCC integration only works from the IDE (not FBCMD) so it’s not possible to check the FBV file in automatically when running from CC.NET.
One alternative to using persistent variables is to save the build number to a separate INI file (or similar) using the INI File actions. You can then check that file into source control and have it checked out and checked in automatically as part of your build process. That means that local copies of the FBV file will never interfere with the global build number. Please let me know if you’d like more information on how to achieve this. (You’ll also need to tell CC.NET to ignore changes to that file when triggering builds.)
If the FBV file is not checked in to version control, then it sounds like you’ve found a bug. What version of FB are you using? Do you have any other options (apart from “Is Persistent”) enabled on that variable?
Regards,
Angus
We are not checking the FBV into source control, or the INI file. Using version 5.5.0.627 at the moment.
Options checked on “Builditeration” are Make Available as Environment Variable and Persistent.
Another thing I’ve noticed today is that if I have the project open, it defaults back to the default variable, no matter how many times the project has been run through CC.NET…and if I make a change and run the project, without saving, and the build fails; every subsequent run of the build uses the same increment. Then I save, and run cc.net, and we’re back to square one.
So basically, we can run FB to get our build correct, no failures. Build increments 1, 2, 3, 4, 5, 6, and each build will label in Fortress. Then we switch over to CC.NET, and the first first time it builds, we get a build increment of 1 (which fails, because Fortress already has that label). So we go into the FBV, up the default value to 10, save, go back to CC.NET.
Time passes, we increment up to, say, 100. We find we need to look at something in the FBV project. We open it, close it, and later the build in CC.NET fails with an error message - label of 11 already exists.
Or, we need to make a change in the FBV project. We open it, change it, run it, label of 11 already exists. We up the default value to 101, run it, get a green build, save it, close it.
Run CC.NET, build fails - label of 102 already exists.
Hi Andy,
Thanks for the reply and explanation. There was a bug involving the unexpected reset of Persistent variables with “Make Available as Environment” enabled, which was fixed in the latest official release. It seems to have missed the Version History changes list, I’ll fix that ASAP.
Could you upgrade to build 707 (available from the Download page) and see if the problem persists, please?
Regards,
Angus