.net assemblyinfo & win32 version info

FinalBuilder Discussion
1
Hi everybody,
 
We have a problem with the different ways in which vc++ 2005 projects & .net assemblies are assigned the fileversion & assemblyversion respectively.
 
Our projects consist of large number of vc++ 2005 projects along with some .net 2.0 projects. We want to update the versions of executables after every build (increment the buildversion/ build number).
 
We store version information for entire project in an INI file which has following fields:
 
majorverion, minorversion, buildversion & releaseversion.
 
For vc++ projects we define 'VersionInfo' property set from 'Win32 Version Info' and for .Net projects, we define '.NetAssemblyInfo' property set from '.Net Assembly Info'. And we load these property-sets from the INI file, using 'PropertySet load from INI file' action.
 
To update the version of vc++ 2005 project executables we use 'win 32 version info updater' action and to update the version of .net project executables we use 'AssemblyInfo updater' action. Now, what we see is, if the ini file contains following values.
 
[VersionInfo]
MajorVersion=1
MinorVersion=0
ReleaseVersion=0
BuildVersion=2
 
Then, vc++ project executables will get 1.0.0.2 as fileversion and .net executables will get 1.0.2.0 as assemblyversion. For .net project executables, we are updating the 'assemblyfileversion' attribute in 'AssemblyInfo updater' action and assigning the 'AssemblyVersion' value to 'AssemblyFileVersion'. This makes project executables from same build have different fileversions (although they both mean the same) i.e. 1.0.0.2 & 1.0.2.0.
 
One solution could be instead of equating .net executable fileversion to its assemblyversion, we could assign fileversion number that looks equivalent to vc++ project executables. Only problem with this might be the assemblyversion & fileversion of the same .net executable would have different values or formats.
 
We would like to know what the best practice is.
 
BTW, we are using FinalBuilder 6.2.0.1019
 
Thanks in advance and sorry for such a long post.
2

Hi

I’m not sure what best practice is… it always annoys me that Microsoft changed the order of the release and build numbers in .net, just makes for the sort of confusion you are dealing with. Personally I think people don’t care what the order is, they just read the value as one string… so if they see 1.0.0.2 in win32 and 1.0.0.2 on a .net exe or assembly they read them as being the same.

HTH

3

Thanks a lot for your quick reply...

We would probably go with keeping same fileversion for all the projects.

 

Regards,

Sankalp.