Qual è il modo corretto di gestire la versione dell'assembly?

Question

Non vedo l'ora di implementare una build giornaliera per un progetto imminente.

Ma prima di farlo, devo sapere come eseguire correttamente la versione di un assieme.

Ho le seguenti preoccupazioni:

• Nel caso in ogni assemblea avere un numero di versione indipendente o dovrebbe tutti condividono la stessa versione?
• Devo usare una versione * per la compilazione e la revisione?
• La revisione è rilevante per la creazione giornaliera?

Answer 1

Stampiamo tutti i gruppi all'interno dei nostri prodotti con lo stesso numero di versione utilizzando le seguenti operazioni:

• collegare tutti i gruppi a un AssemblyInfoCommon.cs contenenti la versione informazioni numero: cfr here per un esempio.

• Generare il file AssemblyInfoCommon.cs come parte della costruzione utilizzando (nel nostro caso) Nant asminfo compito, Cruise Control NET e la revisione SVN etichettatrice

Nel nostro caso, abbiamo don usare la versione * Tutte le versioni implementate sono costruite sul server di build. Non ci preoccupiamo del numero di versione sui nostri desktop.

Answer 2

Così Ciascun gruppo deve avere la stessa versione che è tipicamente una combinazione della versione finale vale a dire 3.4 + il numero di build, che è una sequenza che rappresenta il numero di volte che il rilascio è stato compilato sul server di build. La revisione è rilevante perché dimostra il numero di build che hai creato per quella versione. Puoi davvero farlo in uno dei 2 modi. Il primo modo sarebbe che se hai pianificato una versione, ovvero 3.4, quando inizi a lavorare su quella versione, allora questo è il tuo numero di versione principale e il numero della tua versione minore aumenta con la build. Un altro modo per farlo è quello di controllare attentamente le versioni di build in quanto quando si è pronti per eseguire il rilascio su QA/Regression si imposta la versione principale su 3.4 e si lascia il numero di versione minore su 0. Si mantiene le cose strettamente controllate in questo modo fino al tuo rilascio. In questo modo è possibile controllare la numerazione del service pack tramite il numero di versione secondario. Spero che questo ti aiuti.

Answer 3

La risposta dipende in realtà da ciò che si sta tentando di ottenere con i numeri di versione dell'assieme. Se si sta eseguendo una distribuzione ClickOnce e si desidera eseguire download indipendenti degli assembly aggiornati, è necessario che ogni assembly sia sottoposto a versioni indipendenti, altrimenti, penso che sia spesso piacevole avere le versioni di assieme corrispondenti al numero di versione del software. In scenari più complessi potresti aver bisogno di un'altra strategia.

Uno schema utilizzato in un'azienda precedente era major.minor.revision.build: nella versione 1.0 del prodotto, la versione dell'assembly e la versione del file di assemblaggio su ciascun assieme era 1.0.0.1129 (ad esempio). Ciò ha reso facile abbinare quali gruppi facevano parte di quale versione del software, fino al numero di build. Abbiamo raggiunto questo obiettivo utilizzando una ricerca di precompilazione e sostituendola in ciascun file AssemblyInfo.cs per sostituire un token con i numeri di versione forniti dal nostro processo di compilazione automatizzato.

Answer 4

Normalmente accetto che tutti gli assembly abbiano lo stesso numero di versione; tuttavia, vorrei fare un avvertimento a questo. Se uno degli assembly viene utilizzato da qualche altra parte al di fuori di questo progetto o se viene considerato un progetto proprio, dovrebbe avere il proprio numero di versione. Probabilmente dovrebbe anche essere spostato da quella soluzione e nella sua. L'unica ragione per cui ho detto questo è che ho visto numerose occasioni in cui le persone hanno un assemblaggio che viene utilizzato in un paio di altri luoghi, ma principalmente in un posto e cercano di mantenere la versione corretta. È una cattiva idea farlo. Penso che il Principio di Responsabilità Unica si applichi anche a livello di soluzione/progetto.

Per quanto riguarda la numerazione, sono d'accordo con Guy Starbuck (major.minor.revision.build). È così che l'ho sempre fatto e ha sempre funzionato bene.

Answer 5

Abbiamo una grande app (centinaia di assiemi) con rilasci frequenti (circa 1 al mese). Siamo andati per "dare ad ogni assemblaggio la stessa versione" ma è una costante fonte di preoccupazione per me che gli assembly per la versione 1 sono completamente incompatibili con quelli di un'altra, nonostante il fatto che le interfacce di queste assemblee cambino raramente (se mai).

Se questo è il caso per voi, potreste trarre vantaggio dalla versione degli assembly separatamente: ogni volta che aggiornate l'assembly, si preoccupa solo di incrementare il numero di versione nei casi in cui si desidera interrompere l'associazione dell'assieme (ad esempio se l'interfaccia cambia, o le modifiche sono altrimenti significative che si desidera impedire a qualcuno di utilizzare accidentalmente la versione precedente).