Auto-Incrementing Build/Revision numbers 
Author Message
 Auto-Incrementing Build/Revision numbers

How, exactly, do I get VS.NET to auto-increment my build/revision numbers?

Perhaps I'm just thinking about it in the wrong light, but everytime I build
my solution, the build and revision numbers are exactly the same: 809.4011.

In the AssemblyInfo file I have the AssemblyVersion attribute set to
"1.0.*", so I'm under the impression that VS.NET is supposed to be managing
it for me.

Do I have a different definition of "build" than VS.NET does?

I must be missing something amazingly obvious here, but in all the books
I've looked in, I can't find the answer to my question.

Thanks for your help,

--
mikey k
Mike Kolitz MCSE 2000
MS-MVP - Windows XP



Sun, 05 Sep 2004 16:29:10 GMT  
 Auto-Incrementing Build/Revision numbers
If you are using Windows Explorer, it doesn't update the version number upon
recompiling (even though it will update the time). You have to click to
another folder and then click back to the folder with the .NET app. Even
doing a Refresh doesn't work.

--
Moving from VB6 to VB.NET?  It just got easier...
"The .NET Languages: A Quick Translation Guide"
www.bischofsystems.com/vbnet.asp


Quote:
> How, exactly, do I get VS.NET to auto-increment my build/revision numbers?

> Perhaps I'm just thinking about it in the wrong light, but everytime I
build
> my solution, the build and revision numbers are exactly the same:
809.4011.

> In the AssemblyInfo file I have the AssemblyVersion attribute set to
> "1.0.*", so I'm under the impression that VS.NET is supposed to be
managing
> it for me.

> Do I have a different definition of "build" than VS.NET does?

> I must be missing something amazingly obvious here, but in all the books
> I've looked in, I can't find the answer to my question.

> Thanks for your help,

> --
> mikey k
> Mike Kolitz MCSE 2000
> MS-MVP - Windows XP



Sun, 05 Sep 2004 16:55:14 GMT  
 Auto-Incrementing Build/Revision numbers
Hi Brian.

Thanks for your response.

I'm not using Explorer to determine the build number.  Actually, I have a
label on the form which is reporting the version to me with this code:

label1.text =
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString
()

Incidentally, when I built the solution this morning, the revision number
changed from .4011 to .18643, but this still isn't what I want to see.

Perhaps I should clarify as to what behavior I'm looking for.
When I build a solution for the first time, I want that to be .1 (assuming I
set it to start there).  The second time to be .2, the third to be .3, and
so on.  I don't want these seemingly random build and revision numbers.

Is it possible to do this?

--
mikey k
Mike Kolitz MCSE 2000
MS-MVP - Windows XP


Quote:
> If you are using Windows Explorer, it doesn't update the version number
upon
> recompiling (even though it will update the time). You have to click to
> another folder and then click back to the folder with the .NET app. Even
> doing a Refresh doesn't work.

> --
> Moving from VB6 to VB.NET?  It just got easier...
> "The .NET Languages: A Quick Translation Guide"
> www.bischofsystems.com/vbnet.asp



> > How, exactly, do I get VS.NET to auto-increment my build/revision
numbers?

> > Perhaps I'm just thinking about it in the wrong light, but everytime I
> build
> > my solution, the build and revision numbers are exactly the same:
> 809.4011.

> > In the AssemblyInfo file I have the AssemblyVersion attribute set to
> > "1.0.*", so I'm under the impression that VS.NET is supposed to be
> managing
> > it for me.

> > Do I have a different definition of "build" than VS.NET does?

> > I must be missing something amazingly obvious here, but in all the books
> > I've looked in, I can't find the answer to my question.

> > Thanks for your help,

> > --
> > mikey k
> > Mike Kolitz MCSE 2000
> > MS-MVP - Windows XP



Mon, 06 Sep 2004 00:33:46 GMT  
 Auto-Incrementing Build/Revision numbers
Hey Mike,

That's interesting that the Reflection class isn't reporting the correct
version number. Maybe you should do incremental comparisons between what the
Reflection class says versus going into Explorer and right-clicking then
selecting Properties. That will  tell you if something is acting strange.

Re .1, .2, etc. I don't think you can do that. .NET uses the system clock to
derive the version numbers. So it will always create some semi-random number
(I don't know the algorithm). Maybe someone else can chime in if they found
a way to set the increment to be .1, .2, etc.

By the way, here is the function I've been using and it seems to be
accurate. It uses the Reflection and Diagnostics namespaces. It's in C#, but
you can tell what its doing.

public string Version()

{

string fileLocation;

fileLocation = Assembly.GetExecutingAssembly().Location;

return "ver: " + FileVersionInfo.GetVersionInfo(fileLocation).FileVersion;

Quote:
}

--
Moving from VB6 to VB.NET?  It just got easier...
"The .NET Languages: A Quick Translation Guide"
www.bischofsystems.com/vbnet.asp


Quote:
> Hi Brian.

> Thanks for your response.

> I'm not using Explorer to determine the build number.  Actually, I have a
> label on the form which is reporting the version to me with this code:

> label1.text =

System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString
Quote:
> ()

> Incidentally, when I built the solution this morning, the revision number
> changed from .4011 to .18643, but this still isn't what I want to see.

> Perhaps I should clarify as to what behavior I'm looking for.
> When I build a solution for the first time, I want that to be .1 (assuming
I
> set it to start there).  The second time to be .2, the third to be .3, and
> so on.  I don't want these seemingly random build and revision numbers.

> Is it possible to do this?

> --
> mikey k
> Mike Kolitz MCSE 2000
> MS-MVP - Windows XP



> > If you are using Windows Explorer, it doesn't update the version number
> upon
> > recompiling (even though it will update the time). You have to click to
> > another folder and then click back to the folder with the .NET app. Even
> > doing a Refresh doesn't work.

> > --
> > Moving from VB6 to VB.NET?  It just got easier...
> > "The .NET Languages: A Quick Translation Guide"
> > www.bischofsystems.com/vbnet.asp



> > > How, exactly, do I get VS.NET to auto-increment my build/revision
> numbers?

> > > Perhaps I'm just thinking about it in the wrong light, but everytime I
> > build
> > > my solution, the build and revision numbers are exactly the same:
> > 809.4011.

> > > In the AssemblyInfo file I have the AssemblyVersion attribute set to
> > > "1.0.*", so I'm under the impression that VS.NET is supposed to be
> > managing
> > > it for me.

> > > Do I have a different definition of "build" than VS.NET does?

> > > I must be missing something amazingly obvious here, but in all the
books
> > > I've looked in, I can't find the answer to my question.

> > > Thanks for your help,

> > > --
> > > mikey k
> > > Mike Kolitz MCSE 2000
> > > MS-MVP - Windows XP



Mon, 06 Sep 2004 02:39:51 GMT  
 Auto-Incrementing Build/Revision numbers
According to Jeffrey Richter in his book, "Applied Microsoft .NET Framework
Programming", Microsoft Press, he warns against using the automatic build
numbering.  He states that if there are any assemblies that reference this
assembly, that automatic versioning will break them.  Here is the quote from
page 61:

<QUOTE>
"The CSC.exe and AL.exe tools support the ability to automatically increment
the assembly version number with each build.  This feature is a bug and
shouldn't be used vecause changing the assembly version number will break
any assemblies that reference this assembly.  The AssemblyInfo.cs file that
Visual Studio.NET automatically creates for you when you create a new
project is in error:  it sets the AssemblyVersion attribute so that its
major and minor parts are 1.0 and that the build and revision parts are
automatically updated by the compiler.  You should definitely modify this
file and hard code all four parts of the assembly version number.
</QUOTE>

He also states that there are three version numbers associated with an
assembly:  The AssemblyFileVersion, the
AssemblyInformationalVersionAttribute, and the AssemblyVersion.  He states
that the CLR only cares about the last one and that the other two are
informational only, ignored by the CLR.

I recommend his book.  I am still reading it, but it provides wealth of
"nuts and bolts" information on the CLR and how it works.

Cheers,

Chris


Quote:
> How, exactly, do I get VS.NET to auto-increment my build/revision numbers?

> Perhaps I'm just thinking about it in the wrong light, but everytime I
build
> my solution, the build and revision numbers are exactly the same:
809.4011.

> In the AssemblyInfo file I have the AssemblyVersion attribute set to
> "1.0.*", so I'm under the impression that VS.NET is supposed to be
managing
> it for me.

> Do I have a different definition of "build" than VS.NET does?

> I must be missing something amazingly obvious here, but in all the books
> I've looked in, I can't find the answer to my question.

> Thanks for your help,

> --
> mikey k
> Mike Kolitz MCSE 2000
> MS-MVP - Windows XP



Mon, 06 Sep 2004 03:47:27 GMT  
 Auto-Incrementing Build/Revision numbers
Hi Brian,

Thanks for your responses!

It looks like the Reflection class is reporting the build and revision
correctly, as Explorer is reporting the same version number.

It looks like my understanding of how the build numbers are incremented was
what was wrong :)

I find it curious, though, that Microsoft would implement a system like
this, as opposed to how their own build-numbering system works.

Oh well, I guess I'll deal :)

Thanks!

--
mikey k
Mike Kolitz MCSE 2000
MS-MVP - Windows XP


Quote:
> Hey Mike,

> That's interesting that the Reflection class isn't reporting the correct
> version number. Maybe you should do incremental comparisons between what
the
> Reflection class says versus going into Explorer and right-clicking then
> selecting Properties. That will  tell you if something is acting strange.

> Re .1, .2, etc. I don't think you can do that. .NET uses the system clock
to
> derive the version numbers. So it will always create some semi-random
number
> (I don't know the algorithm). Maybe someone else can chime in if they
found
> a way to set the increment to be .1, .2, etc.

> By the way, here is the function I've been using and it seems to be
> accurate. It uses the Reflection and Diagnostics namespaces. It's in C#,
but
> you can tell what its doing.

> public string Version()

> {

> string fileLocation;

> fileLocation = Assembly.GetExecutingAssembly().Location;

> return "ver: " + FileVersionInfo.GetVersionInfo(fileLocation).FileVersion;

> }

> --
> Moving from VB6 to VB.NET?  It just got easier...
> "The .NET Languages: A Quick Translation Guide"
> www.bischofsystems.com/vbnet.asp



> > Hi Brian.

> > Thanks for your response.

> > I'm not using Explorer to determine the build number.  Actually, I have
a
> > label on the form which is reporting the version to me with this code:

> > label1.text =

System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString

- Show quoted text -

Quote:
> > ()

> > Incidentally, when I built the solution this morning, the revision
number
> > changed from .4011 to .18643, but this still isn't what I want to see.

> > Perhaps I should clarify as to what behavior I'm looking for.
> > When I build a solution for the first time, I want that to be .1
(assuming
> I
> > set it to start there).  The second time to be .2, the third to be .3,
and
> > so on.  I don't want these seemingly random build and revision numbers.

> > Is it possible to do this?

> > --
> > mikey k
> > Mike Kolitz MCSE 2000
> > MS-MVP - Windows XP



> > > If you are using Windows Explorer, it doesn't update the version
number
> > upon
> > > recompiling (even though it will update the time). You have to click
to
> > > another folder and then click back to the folder with the .NET app.
Even
> > > doing a Refresh doesn't work.

> > > --
> > > Moving from VB6 to VB.NET?  It just got easier...
> > > "The .NET Languages: A Quick Translation Guide"
> > > www.bischofsystems.com/vbnet.asp



> > > > How, exactly, do I get VS.NET to auto-increment my build/revision
> > numbers?

> > > > Perhaps I'm just thinking about it in the wrong light, but everytime
I
> > > build
> > > > my solution, the build and revision numbers are exactly the same:
> > > 809.4011.

> > > > In the AssemblyInfo file I have the AssemblyVersion attribute set to
> > > > "1.0.*", so I'm under the impression that VS.NET is supposed to be
> > > managing
> > > > it for me.

> > > > Do I have a different definition of "build" than VS.NET does?

> > > > I must be missing something amazingly obvious here, but in all the
> books
> > > > I've looked in, I can't find the answer to my question.

> > > > Thanks for your help,

> > > > --
> > > > mikey k
> > > > Mike Kolitz MCSE 2000
> > > > MS-MVP - Windows XP



Mon, 06 Sep 2004 03:44:51 GMT  
 Auto-Incrementing Build/Revision numbers

Quote:

>label1.text =
>System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString

FWIW, Application.VersionNumber is a shorter way of doing this but still isn't what you want.  I too have been trying to find a replacement for the old autoincrement, without success.

-- Harry --



Thu, 09 Sep 2004 01:58:38 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. command line build...turn on or off the auto-increment option

2. How to auto increment number in Access Table through VB form

3. Incrementing build number

4. auto incrementing numbers in Access through Vb forms

5. Long auto-incrementing number??

6. How to make build autoincrement version or build number

7. Adding an Auto Incrementing field

8. need help on getting the auto-increment value of a field BEFORE updating recordset

9. Auto Increment Field after Make table query

10. auto increment function

11. Adding an auto incrementing counter to a form.

12. auto increment for next month

 

 
Powered by phpBB® Forum Software