Re: VB Project & SourceSafe question

From: Ralph (msnews.20.nt_consulting32_at_spamgourmet.com)
Date: 03/01/05 

Date: Tue, 1 Mar 2005 11:59:42 -0600

"Bryan Dickerson" <txprphan@netscape.net> wrote in message
news:%23FFKg5aHFHA.3912@TK2MSFTNGP10.phx.gbl...
> Sounds good, I'll give it some thought.
>
> What about versions of OCXs, DLLs, EXEs vs. time-stamps?? Do you favor
one
> over the other? Right now I favor time stamps, 'cause I don't check out
the
> project file everytime I re-build the file and let it increment the
version
> number. I actually used to try and do that and found that the number
that's
> incremented is the build number, not the Major or Minor version so that
the
> version that gets on the OCX, DLL or EXE is likely to be the same as the
one
> before that I was trying to fix. That's my experience, at least.
>

Bryan,

When it comes to "Versioning" you are pretty much on your own. A "standard"
versioning struct has been a part of the Windows SDK/API since the Win286
days, however, it has been hit 'n miss since day one. Part of the problem is
about everyone can agree on basic attributes (name, major, minor, build,
revision, dates, ...), but the management of this info - where they should
be stored, how they should be queried, and when they should be set - is all
up to the builder and the tools at hand.

If you need a good example - just look at the nonsense you have to go
through to discover what Windows OS version you are running.

Another part of the problem is contained the practical precept "Never go to
sea with two clocks". ie, all these attributes are interesting, and worth
collecting - but what are the rules if you have two different sets of
interesting facts about two components? Major::Minor::Build::Revision is
useful, since we can generally agree that the bigger number wins. But what
do you do with a component timestamped "4.3.2 today::noon" and another
timestamped "4.4.1 yesterday::noon"?

When it comes to ActiveX DLLs and OCXs - it really doesn't matter what
scheme you use - as far as the OS (COM) is concerned - the GUIDs and ProgIDs
rule. You have to come up with your own routines to determine who goes and
who stays.

Generally I would avoid timestamps - they are an accident waiting to happen.
Too many toys can fool with them.

With VSS you can label items to create "versions" but they will have no
relationship to anything you set in the App object unless you make it so.
Personally I would always check out the .vbp, set major and minor to
deliverables, and just let the build number run. (Resetting it when you
reset the minor) Confine .vbp and .grp files to each sandbox - never share.
Use 'Main.vbp' for deliveries.

You can use embedded keywords to attach VSS versions to VB code...
   ' -----------------------------------------
   ' HEADER - MODULE
   ' $Workfile: $
   ' $Modtime: $
   ' $History: $
   Const szRevision As String = "$Revision: $"
   '$NoKeywords: $

A PITA to go the other way. Hint - shell scripts greping VB files and
generating VSS command lines.

There are 3rd tools to manipulate the binary embedded version numbers in VB.
You can do it yourself with a hex editor.

The only time I would attempt to specifically attach version info to a
component, for use in the outer-world, is when it is an official build from
the main store.

Whatever you decide on - keep it simple and automated.

-ralph