By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,417 Members | 1,178 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,417 IT Pros & Developers. It's quick & easy.

Assembly Version

P: n/a
Hi,

Can VB.Net change the next assembly version automatically when I compile the
program?

<Assembly: AssemblyVersion("1.0.0.1")>
<Assembly: AssemblyFileVersion("1.0.0.1")>

Thanks

James
Jan 5 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
James Wong wrote:
Can VB.Net change the next assembly version automatically when I compile the
program?
Yes, but not, IMHO, to anything useful or meaningful.
<Assembly: AssemblyVersion("1.0.*.*")>
This will generate the last two parts of the version based on rules best
known to Visual Studio itself.
However, if your Assemblies go anywhere near the Global Assembly Cache,
I would recommend /against/ using the above. Take control of the
version numbering yourself in such cases. Otherwise, you can wind up
with [literally] dozens of versions cluttering up the GAC, with little,
if any, chance of working out which ones you can safely get rid of...

HTH,
Phill W.
Jan 5 '07 #2

P: n/a
James Wong wrote:
Can VB.Net change the next assembly version automatically when I
compile the program?
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?...ml&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,

--

(O)enone
Jan 5 '07 #3

P: n/a


"Oenone" <oe****@nowhere.comwrote in message
news:#c*************@TK2MSFTNGP06.phx.gbl...
James Wong wrote:
>Can VB.Net change the next assembly version automatically when I
compile the program?

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?...ml&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,

--

(O)enone
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
Jan 5 '07 #4

P: n/a
"James Wong" <cp*******@nospam.nospamschrieb:
Can VB.Net change the next assembly version automatically when I compile
the program?

<Assembly: AssemblyVersion("1.0.0.1")>
<Assembly: AssemblyFileVersion("1.0.0.1")>
Check out the documentation on the constructors of
'AssemblyVersionAttribute' and 'AssemblyFileVersionAttribute'. If you want
build and release number to be set automatically, use a version
specification like "1.0.*".

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Jan 5 '07 #5

P: n/a
Mythran wrote:
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?
We have some fairly specific requirements for DLL versioning, a very
disciplined release build procedure, and some custom-written solutions for
application deployment too. We don't use the GAC at all. For our purposes
the macro approach I described works perfectly. It may not for others, but
it's a possible solution and certainly worthy of consideration IMO.

--

(O)enone
Jan 5 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.