Hello, I am having an issue with the AssemblyVersion not updating when I update the AssemblyInfo.vb and also update the version information in the final builder project itself. Can someone explain to me what I am doing wrong? A group of us has recently taken over the builds and we are moving to a new distribution and need to bump the version numbers on all of our projects. We originally ran a script to update the AssemblyVersion tags in the AssemblyInfo.vb files and when we ran a build, they were back to the original version #'s. Any help would be greatly appreciated!
We are using FinalBuilder 4.2 (with plans to upgrade after this major release) and this pertains to our VS 2005 projects, mostly written in VB.NET
thanks!
Hi Matt,
Would it be possible for you to send the FinalBuilder project to support [at] finalbuilder.com?
Thanks,
Paul.
a little more detail on what we are seeing... we have various .NET dlls that are all at version 6.30.x.x .. we would like to bump them all up to 6.40.0.0 and have them increment from there. we are compiling each dll with a "Build VS.NET Solution" action. we initially tried to update the AssemblyVerion and AssemblyFileVersion in the AssemblyInfo.vb file to 6.40.0.0, but when we ran FB, the dlls were built but reverted back to 6.30.x.x (incremented by 1 more).
we have also tried to delete the .fdb files for each project and to manually set the version numbers in the "Assembly Info" tab of the action, with varied success.. but at some point, the dlls always seem to revert back to the 6.30.x.x version. We are having a hard time figuring out where this number is coming from. Is it stored somewhere in the .fbz4 file? Is there anyway to force it to just look at what is in the AssemblyInfo.vb file and just increment that? I had a simliar problem with VC 6 c++ dlls and i ended up just writing my own action to parse the .RC file, increment the version and then resave it before i built the project.
hope that made a little more sense.. I will try to zip up a project to send along as well, if that will help. is the .NET solution also needed? .fbd files ?
mike martin
For example, for one single dll, i somehow got it to finally build as 6.40.0.0 .... Now if i manually go into the .fbd file and bump it up to say 6.40.0.26 (just for testing purposes) and then recompile, the dll is now correclty at 6.40.0.27.
but if i close FB and delete the .fbd, (the AssemblyInfo.vb is still correctly at 6.40.0.27) then reopen and rebuild, it reverts back to 6.40.0.1 in the dll and the AssemblyInfo.vb is also rolled back.. where is it getting this number from?
well i apologize. part of our problem was that we were doing a full StarTeam checkout before we built. and i think that the .fdb files were being overwritten… at least i think that is what the problem was, or part of it.
so it seems that the .fdb file has the final say in the version number? so my solution was to update all of the .fdb files and then check them in. everything is now correctly on 6.40.x.x … but i am still curious about when i delete the .fdb, where does it get the version number from on the next build that it seems to be reverting back to? because it still doesnt seem to be using what is in the AssemblyInfo.vb file, which I thought it should be.