Qual è il modo migliore per utilizzare gli attributi di versioning dell'assembly?

Question

AssemblyVersion e AssemblyFileVersion sono gli strumenti integrati per la gestione dei numeri di versione. Assemblee NET. Mentre il framework offre la possibilità di determinare automaticamente le parti meno significative di un numero di versione (build e revisione, in termini Microsoft), trovo il metodo per questo piuttosto debole, e senza dubbio ne ho molti altri.

Quindi vorrei chiedere, quali modi sono stati determinati per fare il miglior lavoro di avere numeri di versione che riflettano meglio la versione effettiva di un progetto? Hai uno script pre-build che imposta parte della versione su data e ora o versione del repository per la tua copia di lavoro di un progetto? Usi solo la generazione automatica fornita dal framework? O qualcos'altro? Qual è il modo migliore per gestire il versioning di assembly / file?

Answer 1

Nel mio progetto attuale, utilizziamo il numero di revisione di Subversion come la parte meno significativa (build) del numero di versione e utilizziamo uno script Nant per creare il file AssemblyInfo del progetto. Usiamo lo stesso numero di versione per entrambi gli attributi AssemblyVersion e AssemblyFileVersion. (Le altre tre parti sono major.minor.point, dove major.minor verrà incrementato ogni volta che si verifica una modifica dello schema del database e il punto viene incrementato per ogni versione.)

Abbiamo iniziato con il numero di build che veniva semplicemente incrementato, ma ciò richiedeva che il file di versione venisse archiviato per ogni build e causasse conflitti durante l'unione. Quando ciò si è rivelato inattuabile, abbiamo iniziato a utilizzare CruiseControl.NET per generare il numero di build, ma ciò ha reso difficile la riproduzione manuale di build specifiche. Alla fine siamo passati all'attuale sistema (revisione della sovversione).

Nota: Sfortunatamente con .NET, non è possibile ricreare perfettamente una build da una revisione passata, poiché i compilatori .NET codificano il timestamp corrente nel file oggetto durante la compilazione. Ogni volta che compili lo stesso codice, ottieni un file oggetto diverso.

Answer 2

Vedo molti post qui sull'utilizzo del numero di revisione della sovversione come componente della versione dell'assembly. Attenzione: i 4 numeri di versione disponibili in Windows (abcd) sono ciascuno limitato a 16 bit (max = 65535). Il numero di revisione della sovversione può facilmente superare questo limite, soprattutto se si ospitano più progetti nello stesso repository.

Answer 3

In un precedente lavoro, in cui avevamo usato Subversion, avevo uno script nant eseguito su ccnet per estrarre la versione del repository e l'ho usato come numero finale.

In questo lavoro, utilizziamo VSS (otturatore), quindi non è proprio un'opzione, quindi abbiamo una politica di aggiornamento manuale, con le seguenti linee guida:

• Principali: modifiche significative (> 25%) o aggiunte nella funzionalità o nell'interfaccia.
• Minori: piccole modifiche o aggiunte alla funzionalità o all'interfaccia.
• Build: piccole modifiche che interrompono l'interfaccia.
• Revisione: risolto un build che non cambia l'interfaccia.

Manteniamo anche l'Assemblea & amp; le versioni dei file sincronizzate. La versione dell'Assemblea può essere facilmente letta in modo programmatico, mentre la versione del file può essere visualizzata come colonna in modalità Dettagli in Esplora risorse.

Answer 4

I nostri script di build iniettano il numero di changeset da TFS nella versione. In questo modo sappiamo esattamente quali sono i check-in nella build.

Answer 5

Abbiamo il nostro server di build CruiseControl.NET che incorpora il numero di elenco delle modifiche forzato nel AssemblyFileVersion - questo ci consente di risalire al codice sorgente per qualsiasi assembly creato dal server di build. (Costruiamo sempre dal ramo principale.)

Per gli assiemi a cui faranno riferimento i clienti, lasciamo la costante AssemblyVersion a meno che non vi siano modifiche sostanziali, nel qual caso incrementiamo la versione per garantire che il codice del cliente venga ricostruito rispetto alla nuova versione.

Answer 6

Usiamo il controllo delle versioni da sovversione e facciamo in modo che i buildscripts aggiornino le informazioni sulla versione dell'assembly, quindi i checkin di origine controllano il controllo delle versioni.

Answer 7

Tendiamo a incorporare la data di rilascio (o build) nell'assembly. Ad esempio, se costruita oggi, la versione sarebbe "2008.10.06" (lo script di build lo aggiorna).

Answer 8

AssemblyVersionAttribute fa parte dell'identità di un assembly. Cambiando ciò significa che si tratta di un assembly diverso e che i programmi che si collegano a quell'assembly devono essere ricompilati / collegati o è necessario applicare una politica di versione. Non ci è sembrato interessante, quindi abbiamo scelto di aumentare AssemblyVileVersion per ogni aggiornamento rapido e di modificare AssemblyVersion solo per ogni versione principale. Siamo consapevoli che questa decisione riporta in parte l'inferno di win32 dll. Aumentiamo AssemblyFileVersion per ogni build ed etichettiamo / etichettiamo il sistema di controllo della versione con quella versione in modo da sapere da quale fonte proviene il binario.