Auto-Incrementing Build/Revision numbers
Author |
Message |
Mike Kolit #1 / 7
|
 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 |
|
 |
Brian Bischo #2 / 7
|
 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 |
|
 |
Mike Kolit #3 / 7
|
 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 |
|
 |
Brian Bischo #4 / 7
|
 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.ToStrin g 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 |
|
 |
Chris Dunawa #5 / 7
|
 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 |
|
 |
Mike Kolit #6 / 7
|
 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.ToStrin g 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 |
|
 |
Harry Mof #7 / 7
|
 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 |
|
|
|