Assembly version

  • Thread starter Thread starter Gavin Sullivan
  • Start date Start date
G

Gavin Sullivan

I've been using the date (in YMMDD) format for the build number in the
AssemblyVersion attribute. However, it appears that numbers > 65534 are
invalid!! Bit of a bummer for 2007!!!

Is there a reason for this? 65535 would make sense!?

Is there a work around, patch, etc??

Regards
 
The AssemblyVersion attribute represents the version number of the assembly,
and has nothing to do with the build date. It is a 64-bit number, which is
divided into a Major 32-bit unsigned integer and a Minor 32-bit unsigned
integer. Each of these is sub-divided into 2 16-bit unsigned integers.

Now, if you really wanted to, and I don't recommend this, because this is
not really the appropriate place to do this, but you COULD use the Major
member of the Version for the version number, the MajorRevision number for
the year, the Minor member for the month, and the MinorRevision number for
the day.

There are other Assembly attributes that are more appropriate for storing
date information, such as the Copyright.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

In case of Minimalism, break Philip Glass.
 
Thanks for that.

I new it wasn't to do with dates. I was using the build number this way to
mark a particular release build date, something I got from MSDN and the .net
team's method of versioning the framework.

The information you gave does answer my question though. I'll have to find
another method.

Do you know of any best practice for using the version number?

Regards
 
Just to add to the Version.

I would recommend not using the Date as a Version Number.

Through my experience, when a Customer sees a version number such as
"20041231" makes them think they have an old version and they start calling
to see if there are any new versions or perhaps even go look for another
prog.

If a customer sees v1.04 they are "at the most recent version" :)

Miro
 
Thanks Miro,

A good point. Guess I'll just use sourcesafe's build numbers after all.

Regards
 
Hi Gavin,

This is about the best I can do, as far as a reference is concerned:

http://msdn2.microsoft.com/en-us/library/51ket42z(VS.71).aspx

I might add that you can look at a couple of things to see how Microsoft
thinks about versioning. A Major version is the release of a product, so
that when a product is first released, it is version 1 and so on. The Minor
version is basically an intermittent release of a product, such as Microsoft
..Net Platform version 1.1, which came out after the first version, but prior
to the .Net 2.0 platform. It usually represents some minor additions and
corrections that are added while another version is in the works.

The Build and Revision are used internally by the vendor, for keeping track
of the various builds that are created for testing, and the revisions of
each build that are created in-between. You can often see different build
numbers in beta software. Because I work for a small company, I generally
don't use the Revision number, as we aren't likely to more than a couple of
hundred builds before releasing.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

The shortest distance between 2 points is a curve.
 
Cheers for that.

It does help as I'm basically looking to suggest a new versioning system
into the company I work for.

We'll probably use the project files checkin number from sourcesafe as the
build number and use revision to keep track of the 'toing-and-froing'
between test and development!!

Regards
 
Back
Top