Assembly version

[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

[Kevin Spencer]

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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7******** ******@TK2MSFTN GP04.phx.gbl...

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

[Gavin Sullivan]

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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:%2******** *******@TK2MSFT NGP04.phx.gbl.. .

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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7******** ******@TK2MSFTN GP04.phx.gbl...

>I've been using the date (in YMMDD) format for the build number in the
AssemblyVersio n 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

[Miro]

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
"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:O9******** ******@TK2MSFTN GP06.phx.gbl...

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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:%2******** *******@TK2MSFT NGP04.phx.gbl.. .

>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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7******* *******@TK2MSFT NGP04.phx.gbl.. .

>>I've been using the date (in YMMDD) format for the build number in the
AssemblyVersi on 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

[Gavin Sullivan]

Thanks Miro,

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

Regards

"Miro" <mi******@golde n.netwrote in message
news:%2******** *********@TK2MS FTNGP03.phx.gbl ...

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
"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:O9******** ******@TK2MSFTN GP06.phx.gbl...

>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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:%2******* ********@TK2MSF TNGP04.phx.gbl. ..

>>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
MinorRevisi on 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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7****** ********@TK2MSF TNGP04.phx.gbl. ..
I've been using the date (in YMMDD) format for the build number in the
AssemblyVers ion 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

[Kevin Spencer]

Hi Gavin,

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

http://msdn2.microsoft.com/en-us/lib...2z(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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:O9******** ******@TK2MSFTN GP06.phx.gbl...

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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:%2******** *******@TK2MSFT NGP04.phx.gbl.. .

>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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7******* *******@TK2MSFT NGP04.phx.gbl.. .

>>I've been using the date (in YMMDD) format for the build number in the
AssemblyVersi on 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

[Gavin Sullivan]

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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:em******** *****@TK2MSFTNG P05.phx.gbl...

Hi Gavin,

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

http://msdn2.microsoft.com/en-us/lib...2z(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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:O9******** ******@TK2MSFTN GP06.phx.gbl...

>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

"Kevin Spencer" <un**********@n othinks.comwrot e in message
news:%2******* ********@TK2MSF TNGP04.phx.gbl. ..

>>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
MinorRevisi on 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.

"Gavin Sullivan" <gs*******@inte gratedfm.comwro te in message
news:e7****** ********@TK2MSF TNGP04.phx.gbl. ..
I've been using the date (in YMMDD) format for the build number in the
AssemblyVers ion 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