Assembly Version in Visual Studio?

[Verwijderd]

Hello all!

Mijn vraag gaat over het gebruik maken van versie nummering in Visual Studio.
Visual Studio gebruikt van zichzelf: [Major][Minor][Revision][Build]

Op dit moment is mijn versie als volgt ingesteld: 1.0.*

Nu heb ik gelezen op:
http://haacked.com/archiv...h_Version_of_Version.aspx
Dat er ook ontwikkelaars zijn die de datum gebruiken als versie nummering.

I've always been fond of major.minor.date.build. So, it could be 1.2.60927.456. That would mean v1.2 as the official label of the program, 60927 for the date (Sept 27th, 2006) and build number 456 from the build server (update the version tags last, and check it in with current build+1).

Deze manier lijk me handiger dan die van Microsoft. Alleen heb ik geen idee hoe dit voor elkaar te krijgen.
Is er iemand van jullie die dit weet of die dit gebruikt? Of willen jullie me overtuigen dat de manier van Microsoft handiger en/of beter is?

Alvast bedankt.

[jelmervos]

Denk erom dat de velden beperkt zijn tot 65535. Dus met jaar kom je al niet verder dan 2006.

[RobIII]

Verwijderd schreef op woensdag 30 december 2009 @ 13:24:
Alleen heb ik geen idee hoe dit voor elkaar te krijgen.

Er is een Add-on, als ik me niet vergis op CodePlex, te vinden waarin/waarmee je dit soort zaken haarfijn kunt regelen. Ik zal eens even kijken hoe 'ie ook weer heette.

Ah, gefund!

[ Voor 8% gewijzigd door RobIII op 30-12-2009 13:41 ]

[Verwijderd]

Ok ok. Dat is wel een belangrijk iets. De persoon op dat forum is dan waarschijnlijk ook achter dit probleem gekomen in het jaar 2007 haha.

Welke manieren gebruiken jullie voor versie nummering??

[Dricus]

Het is [major].[minor].[build].[revision] volgens MSDN. Het lijkt me handig dat je je terminologie ook op die manier gebruikt . Als je een asterisk voor de twee laatsten gebruikt, dan zal het build nummer elke dag opgehoogd worden. Het revision nummer is een willekeurig getal.

Ik ben wel benieuwd waarom het gebruik van de datum bij het build nummer handiger zou zijn dan het gebruik van een betekenisloos getal. Wat voor voordeel denk je met zo'n nummering te bereiken?

Het nadeel wat ik zie is (zoals jelmervos hierboven ook al zegt) dat je, door zulke semantiek in versienummers op te nemen, jezelf potentieel onwenselijke beperkingen oplegt. De enige (naar mijn mening!) zinvolle semantiek die ik in versienummers graag wil zien (major, minor en build in ieder geval) is dat versienummers altijd oplopend zijn; hoger is dus nieuwer. Volgorde van significantie is (aflopend): major, minor, build.

[Verwijderd]

Idd. volgorde foutje., sorry haha

Het lijkt me handiger, omdat ik dan precies kan zien wanneer die gebuild is en ik de versies wat makkelijker uit elkaar kan houden. Als dit niet het geval is in de praktijk zeg het me dan maar, ik sta open voor perfectie

[Woy]

Dricus schreef op woensdag 30 december 2009 @ 13:44:
Het is [major].[minor].[build].[revision] volgens MSDN. Het lijkt me handig dat je je terminologie ook op die manier gebruikt . Als je een asterisk voor de twee laatsten gebruikt, dan zal het build nummer elke dag opgehoogd worden. Het revision nummer is een willekeurig getal.

Volgens mij is het build nummer een aantal dagen na een bepaalde datum ( 1-1-2000? ), en het revision nummer het aantal milliseconden sinds middernacht. Het is zeker geen willekeurig getal, maar zeker tijdsafhankelijk. Het zou natuurlijk ook gek zijn als je later op de dag een revision nummer zou krijgen wat lager is dan eerder op de dag.

Aan de hand van het gegenereerde build/revision nummer kun je dus wel achterhalen wat de exacte tijd van het builden is. Vroeger werden de nummers anders gegenereerd, maar met die strategie liepen ze inderdaad tegen een overflow op, en dus hebben ze de strategie iets aangepast.

[ Voor 15% gewijzigd door Woy op 30-12-2009 14:19 ]

[Dricus]

Ach, perfectie... Definieer perfectie in dit soort, toch wel een beetje, smaakgevoelige kwesties .

Het voordeel dat je noemt is natuurlijk wel betrekkelijk. Bij 2 versies die op dezelfde dag gebuild zijn heb je het voordeel al niet meer. Versies "uit elkaar houden" kun je ook doen door te kijken welke versie het hoogste build nummer heeft, die wordt bij het gebruik van de asterisk immers ook dagelijks opgehoogd door Visual Studio. In het gros van de gevallen is dat wat je wilt weten als je naar versienummers kijkt: welke is het nieuwst of het oudst? De datum/tijd van builden zou je ook uit het timestamp van de file kunnen halen of uit je versiebeheersysteem (als je binaries in je versiebeheersysteem opneemt).

@Woy: Uit de MSDN:

You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (*). For example, [assembly:AssemblyVersion("2.3.25.1")] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.*")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is random.

[ Voor 3% gewijzigd door Dricus op 30-12-2009 14:21 . Reden: Linkje naar MSDN artikel toegevoegd ]

[Woy]

Dricus schreef op woensdag 30 december 2009 @ 14:19:
Ach, perfectie... Definieer perfectie in dit soort, toch wel een beetje, smaakgevoelige kwesties .
@Woy: Uit de MSDN:

[...]

Ik heb ergens bij Microsoft wel eens andere informatie gelezen. Ik zal eens zoeken of ik de bron nog kan vinden.

Ik kan niet zo snel een bron vinden, maar ik heb het even uitgetest. Het build nummer is het aantal dagen sinds 1 januari 2000, en het revision nr is het aantal seconden sinds middernacht gedeeld door 2.

http://stackoverflow.com/...ssembly-versions-to-dates bevestigd dit in ieder geval ook. Ook http://msdn.microsoft.com/en-us/library/system.version.aspx hier staat het in de community content onderaan.

[ Voor 39% gewijzigd door Woy op 30-12-2009 14:30 ]

[Dricus]

Hmm, da's geinig. Jammer dat de documentatie van Microsoft dit zowel voor VS2005 als VS2008 niet goed weergeeft. Zo wordt je behoorlijk op het verkeerde been gezet.

Conclusie: VS biedt de door de TS gewenste functionaliteit al out-of-the-box zonder dat je binnen afzienbare tijd tegen de door jelmervos genoemde beperking oploopt. Het enige "nadeel" is dat je niet in 1 oogopslag aan het versienummer kunt zien wanneer een bepaalde versie van een assembly gecreëerd is. In mijn vorige post geef ik echter al 2 alternatieve manieren om hier achter te komen .

[Verwijderd]

dat is grapig jah., ik heb het ook even geprobeerd en het werkt idd.

bedankt voor jullie reacties, ben een hoop wijzer geworden betrekking op versie nummering in visual studio.

thnx again

[Woy]

Verwijderd schreef op woensdag 30 december 2009 @ 15:06:
dat is grapig jah., ik heb het ook even geprobeerd en het werkt idd.

bedankt voor jullie reacties, ben een hoop wijzer geworden betrekking op versie nummering in visual studio.

thnx again

Overigens is de versioning zoals je in de quote in je TS voorstelt volgens mij de manier waarop het in VS.NET 2002 ging

[Verwijderd]

vandaar dat ik weinig informatie vond haha thnx all

[Niemand_Anders]

Met Nant is het kinderspel om een AssemblyInfo.cs te bouwen. Zelf gebruik ik year.month.day.svn-rev als versienummer. Release builds worden ook digitaal ondertekend.

Developer builds hebben de standaard VS buildnummers. Persoonlijk heb ik weinig ervaring met MSBuild, maar het zou mij verbazen als je daarmee geen AssemblyInfo.cs bestand zou kunnen genereren..

[Dricus]

Het jammere van NAnt is alleen dat het project (op sourceforge althans) al sinds december 2007 hardstikke dood is.

[mindcrash]

Komt omdat zowat iedereen is overgestapt naar MSBuild volgens mij, aangezien deze gewoon wordt meegeleverd met het .NET Framework en zo'n beetje alles kan wat NAnt ook kan (het is iig erg duidelijk waar MS de inspiratie voor MSBuild vandaan heeft gehaald ). Ook hier is het een koud kunstje om een assemblyinfo.cs te maken (of direct versienummering in de assembly te injecteren).

[ Voor 25% gewijzigd door mindcrash op 31-12-2009 08:30 ]

[Dricus]

offtopic:
Aangezien het topic oorspronkelijk niet over CI gaat heb ik me nog kunnen inhouden om over CruiseControl.NET te beginnen .

[Dlanor74]

Waarom niet gewoon een custom assemblyatribute maken waarin je de datum propt, kan je via reflectie achter de build datum komen

http://msdn.microsoft.com/en-us/library/aa288454(VS.71).aspx

Met custom attributes kan je zelfs je versie nummer tot op methodes specificeren

[ Voor 38% gewijzigd door Dlanor74 op 31-12-2009 13:23 ]