Componenti per il controllo versioni

Tutti gli assembly hanno un numero di versione in quattro parti che concorre a definirne l'identità. Includere la versione per definirne l'identità è fondamentale per distinguere versioni differenti di un assembly ai fini della modalità affiancata.

Questo numero di versione di compatibilità è rappresentato fisicamente da un numero in 4 parti con il seguente formato:

MajorVersion.MinorVersion.BuildNumber.Revision.

Le parti che compongono il numero di versione sono: principale, secondaria, build e revisione. Non viene applicata alcuna semantica. In altre parole, Common Language Runtime non inferisce la compatibilità o altre caratteristiche di un assembly in base alla modalità di assegnazione del numero di versione. La versione 1.0.0.0 di alcuni assembly e la versione 2.1.0.2 sono infatti identità completamente diverse relativamente al caricatore di classe. Gli sviluppatori hanno la facoltà di modificare qualsiasi porzione del numero in base a esigenze specifiche. Sebbene non venga applicata alcuna semantica al formato del numero di versione, è probabile che le singole organizzazioni trovino utile stabilire delle convenzioni di modifica, che presentano il vantaggio di garantire la coerenza e di rendere più semplice la determinazione di informazioni quali la build di provenienza di un determinato assembly. Una convenzione tipica è la seguente:

Principale o secondaria. Le modifiche apportate alla porzione principale o secondaria del numero di versione indica una modifica incompatibile. In base a questa convenzione, quindi, la versione 2.0.0.0 viene considerata incompatibile con la versione 1.0.0.0. Un esempio di modifica incompatibile è una modifica ai tipi di qualche parametro di metodo o la rimozione totale di un tipo o metodo.

Build. Il numero di build viene generalmente utilizzato per distinguere tra build create ogni giorno o rilasci compatibili più piccoli.

Revisione. Le modifiche del numero di revisione sono generalmente riservate a una build incrementale necessaria per correggere un determinato errore. Questo numero viene talvolta definito numero di "correzione errore di emergenza" in quanto spesso è la revisione ad essere modificata quando a un cliente viene fornita una correzione a un errore specifico.

Un assembly con un numero di versione di compatibilità 2.0.0.0 è quindi considerato non compatibile con un assembly il cui numero di versione di compatibilità è 1.0.0.0. Il numero di compatibilità 2.0.2.11 è inoltre considerato QFE in relazione al numero di compatibilità 2.0.2.1.

Vedere anche

Nomi sicuri per il controllo versioni | Riepilogo della distribuzione di package | Appendice A: ulteriori informazioni sulla creazione di package e sulla distribuzione | Appendice B: strumenti per la creazione di package e per la distribuzione