|
#1
|
|||
|
|||
Way to set VB6 project version to 1.2.3.4
The main justification for our group to use VBP is to automatically set the File Version in our group's VB6, VC6 & VS.Net automated builds. It does that job very well. I had planned to use a versioning scheme with 4 chunks:
<major>.<minor>.<sr>.<build> This works (by default) for all source types but VB6. E.G., if I set the Project Version to 1.2.3.4, the resulting VB6 file version is 1.2.0.3. In the VB6 IDE, the Project's Make property only shows 3 version number "chunks". Is there a way around this using VBP? Or will I have to use a 3-chunk scheme? Thanks! |
#2
|
|||
|
|||
That is a limitation of VB6 that VBP does not try to work around. You might be able to use something like StampVer [1], which can modify the version info resource in a compiled executable, to hack around this. But then you'd also have to hack around it in your VB code to retrieve that extra version field. It seems better to use a 3-field format for VB applications, or, depending on how large of numbers you use, you might be able to combine, say sr*1000+build into the revision field and extract it out when showing to the user in the VB app.
[1] http://www.elphin.com/products/stampver.html (although the web site is not currently responsive) |
#3
|
|||
|
|||
So if I understand you correctly, the version number can only be 3 digits, as in 1.2.3, for a vb6 project. My question is this: How big can each number grow before it becomes a problem or error? Would a version number like 1.2.999, the next time it's incremented, turn to 1.3.0 automatically? Does one number at a certain point increment the other numbers, and if so, when?
I am able to increment and set the version number for an executable file, but I don't know if I should worry about it reaching a value to where it won't work. Thank you. |
#4
|
|||
|
|||
It appears that the VB6 version limits are 9999.9999.9999
|
|
|