Oenone said:
Not in the way it worked in VB6; the "asterisk" version number can be
used, but as already pointed out by Phill W., this is less than
satisfactory.
We use a macro to do this for us. It's fairly heavily customised but based
on the original that you can find here:
http://www.jmedved.com/default.aspx?page=vbnet_vb6ver&rendering=xhtml&language=en
Be aware however this will run EVERY time you compile, which can amount to
hundreds of times over the repeated test/debug sequence involved in write
an application. We use the macro just on our clean-build machines, not on
our development machines, so the build number is only actually incremented
when a new version of the component is prepared for release.
HTH,
Why? When you "build" a debug version, it's a new build. If you changed
ANYTHING, it's a different build when you build it. Why not let the
compiler automatically update the build number?
What we do in-house, and yes most of our library assemblies are GAC'ed, is
set the AssemblyVersion attribute to 1.0.*. When we are satisfied with a
particular build in debug mode and we prepare for release, we change it to a
release build and compile and send for Q&A. Once all is done, we create our
installation packages and label it in SourceSafe.
When we need to modify the library, and we have only non-breaking, non-major
changes to the library, we will manually up the minor version to 1.1.* and
keep it at 1.1.* until after we Release. If we have breaking or major
changes, we up the major version to 2.0.*. The way we setup our tests, so
we don't have GAC hell, is our test projects reference the debug assemblies
via a project reference. When we are ready for deployment, our real
projects reference the assemblies from the GAC. Therefore, only Release
assemblies are installed into the GAC via our installers and the debug
assemblies are not.
HTH,
Mythran