Program Version Number

Visual Basic >> Program Version Number In Project Properties in Version Number I see: Major 12, Minor 1, Revision
10.
When I compile my project and via EXE's properties I see Version 12.1.0.10
Where 0 does come from?
Is there any place in VB environment to control that third place in version
number? Now it's always 0.

Thank you
vovan

Visual Studio197

Visual Basic >> Program Version Number
"vovan" <EMail@HideDomain.com> wrote in message
news:EMail@HideDomain.com...

> In Project Properties in Version Number I see: Major 12, Minor 1,
> Revision 10.
> When I compile my project and via EXE's properties I see Version 12.1.0.10
> Where 0 does come from?
> Is there any place in VB environment to control that third place in
> version number? Now it's always 0.

The 0 is called the Build number and it's not something that you can set
with VB. I did a quick Google search and while this question has come up
before, there has been no satisfactory answer that I've seen other than that
a 3rd-party product called VBAdvance "would be making this possible in its
next release." However, that was years ago and that product is no longer for
sale.

I wonder if you simply couldn't create a Version entry in a resource file
with an external tool (like something from the Platform SDK) and control
your info that way or if VB would clobber that during the MAKE process with
its own version data.

Visual Basic >> Program Version Number
"Jeff Johnson" <EMail@HideDomain.com> wrote in message
news:%EMail@HideDomain.com...
>
> "vovan" <EMail@HideDomain.com> wrote in message
> news:EMail@HideDomain.com...
>
>> In Project Properties in Version Number I see: Major 12, Minor 1,
>> Revision 10.
>> When I compile my project and via EXE's properties I see Version
>> 12.1.0.10
>> Where 0 does come from?
>> Is there any place in VB environment to control that third place in
>> version number? Now it's always 0.
>
> The 0 is called the Build number and it's not something that you can set
> with VB. I did a quick Google search and while this question has come up
> before, there has been no satisfactory answer that I've seen other than
> that a 3rd-party product called VBAdvance "would be making this possible
> in its next release." However, that was years ago and that product is no
> longer for sale.
>
> I wonder if you simply couldn't create a Version entry in a resource file
> with an external tool (like something from the Platform SDK) and control
> your info that way or if VB would clobber that during the MAKE process
> with its own version data.

I believe VB "overwrites" it, at least that would be my expectation. You
can, however, open the EXE in VC++ (or any tool capable of editing
resources) and change the FILEVERSION of the Version resource. Of course, VB
doesn't provide a way to get the build number either, so you're also going
to have to use the API to do anything with it. Lot of bother for something
so minor.

--
Mike
Microsoft MVP Visual Basic

Visual Basic >> Program Version Number Jeff Johnson <EMail@HideDomain.com> wrote:
> "vovan" <EMail@HideDomain.com> wrote in message
> news:EMail@HideDomain.com...
>
>> In Project Properties in Version Number I see: Major 12, Minor 1,
>> Revision 10.
>> When I compile my project and via EXE's properties I see Version 12.1.0.10
>> Where 0 does come from?
>> Is there any place in VB environment to control that third place in
>> version number? Now it's always 0.
>
> The 0 is called the Build number and it's not something that you can set
> with VB.

I thought it was the "Revision" number? Officially. I believe VB erroneously calls
the true "Build" number "Revision", but this is the real mccoy.

> I did a quick Google search and while this question has come up
> before, there has been no satisfactory answer that I've seen other than that
> a 3rd-party product called VBAdvance "would be making this possible in its
> next release." However, that was years ago and that product is no longer for
> sale.

Yeah, vbAdvance v3.0 does/did indeed support setting that.
--
.NET: It's About Trust!
http://vfred.mvps.org

Visual Basic >> Program Version Number
"Karl E. Peterson" <EMail@HideDomain.com> wrote in message
news:%EMail@HideDomain.com...

>> The 0 is called the Build number and it's not something that you can set
>> with VB.
>
> I thought it was the "Revision" number? Officially. I believe VB
> erroneously calls the true "Build" number "Revision", but this is the real
> mccoy.

Hmmm. Take a look at this
http://www.dotnet247.com/247reference/msgs/45/225355.aspx

and then this http://msdn2.microsoft.com/en-us/library/system.version.aspx

For what it's worth.

Visual Basic >> Program Version Number Jeff Johnson <EMail@HideDomain.com> wrote:
> "Karl E. Peterson" <EMail@HideDomain.com> wrote ...
>
>>> The 0 is called the Build number and it's not something that you can set
>>> with VB.
>>
>> I thought it was the "Revision" number? Officially. I believe VB
>> erroneously calls the true "Build" number "Revision", but this is the real
>> mccoy.
>
> Hmmm. Take a look at this
> http://www.dotnet247.com/247reference/msgs/45/225355.aspx
>
> and then this http://msdn2.microsoft.com/en-us/library/system.version.aspx
>
> For what it's worth.

Well, they contradict themselves, and therefore agree with me! To wit, on the
second link:

==========================================
major.minor[.build[.revision]]

The components are used by convention as follows:

* Major : Assemblies with the same name but different major versions are not
interchangeable. This would be appropriate, for example, for a major rewrite of a
product where backward compatibility cannot be assumed.

* Minor : If the name and major number on two assemblies are the same, but the
minor number is different, this indicates significant enhancement with the intention
of backward compatibility. This would be appropriate, for example, on a point
release of a product or a fully backward compatible new version of a product.

* Build : A difference in build number represents a recompilation of the same
source. This would be appropriate because of processor, platform, or compiler
changes.

* Revision : Assemblies with the same name, major, and minor version numbers but
different revisions are intended to be fully interchangeable. This would be
appropriate to fix a security hole in a previously released assembly.
==========================================

But which field do *their* compilers actually increment during compilation, hmmm? I
declare a doc bug. :-)
--
.NET: It's About Trust!
http://vfred.mvps.org