Come funziona esattamente la proprietà "Versione specifica" di un riferimento di assembly in Visual Studio?

Oggi ho esaminato più da vicino la proprietà "Versione specifica" dei riferimenti di assembly in Visual Studio 2010. Dopo alcuni esperimenti con risultati imprevisti, ho iniziato a imparare il più possibile sul funzionamento della proprietà. Anche così, mi sembra, non ha tutte le risposte, quindi ecco il mio tentativo di auto-rispondere alla domanda:

Come funziona esattamente la proprietà "Versione specifica" di un riferimento di assembly in Visual Studio?

È una proprietà in fase di compilazione!

Una delle cose più importanti da sapere è che "Versione specifica" è una proprietà che ha effetto in fase di compilazione e non in fase di esecuzione.

Cos'è tutto questo?

Quando viene creato un progetto, i riferimenti di assieme del progetto devono essere risolti al fine di trovare gli assiemi fisici che il sistema di generazione dovrebbe usare. Se viene eseguito il controllo "Versione specifica" (vedere la sezione "Quando è selezionata la" Versione specifica "?"), Influisce sul risultato del processo di risoluzione dell'assembly:

• Il sistema di generazione individua un assembly fisico che può potenzialmente utilizzare
• Il sistema di generazione confronta la versione dell'assembly fisico con la versione dell'assembly memorizzata nel file .csproj per il riferimento dell'assembly
• Se le due versioni dell'assieme sono esattamente le stesse, il processo di risoluzione ha esito positivo e l'assemblaggio fisico trovato viene utilizzato per la compilazione
• Se le due versioni dell'assembly non corrispondono, l'assemblaggio fisico viene scartato e il processo di risoluzione continua individuando l'assembly potenziale successivo
• Se non è possibile individuare più potenziali assiemi fisici, il processo di risoluzione non riesce. Ciò provoca un avviso del compilatore (avviso MSB3245) che indica che non è stato possibile risolvere il riferimento.
• È interessante notare che la build continua quindi! Se il codice non ha riferimenti effettivi all'assembly, la compilazione ha esito positivo (con l'avviso precedentemente citato). Se il codice ha riferimenti, la compilazione fallisce con un errore che sembra che il codice stia usando tipi o spazi dei nomi sconosciuti. L'unica indicazione per cui la build veramente fallito è il MSB3245 avvertimento.

Ordine in cui vengono risolti gli assiemi

L'ordine in cui il processo di risoluzione degli assembly individua i potenziali assembly sembra essere questo:

1. L'assembly a cui fa riferimento l' <HintPath>elemento nel file .csproj
2. Il percorso di output del progetto
3. Il GAC

Notare che se nel GAC esistono diverse versioni dell'assembly, il processo di risoluzione tenta innanzitutto di risolvere l'assembly con la versione più alta. Questo è importante solo se il controllo "Versione specifica" non viene eseguito.

Quando viene selezionata la "Versione specifica"?

Visual Studio basa la sua decisione sull'esecuzione del controllo "Versione specifica" su due informazioni contenute nel file .csproj:

• La presenza o l'assenza <SpecificVersion>dell'elemento e il suo valore (se presente)
• La presenza o l'assenza di informazioni sulla versione nel riferimento dell'assembly

Ecco come appare un tipico riferimento di assieme con le informazioni sulla versione:

<Reference Include="Foo, Version=1.2.3.4, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>True</SpecificVersion>
  <HintPath>..\..\Bar\Foo.dll</HintPath>
</Reference>

Ecco come appare il riferimento all'assemblaggio senza le informazioni sulla versione:

<Reference Include="Foo">
[...]

La tabella seguente mostra quando viene eseguito il controllo "Versione specifica" e quando non lo è.

                            |     Version information
                            |  Present       Not present
----------------------------+------------------------------
<SpecificVersion>           |
- Present, has value True   |    Yes (1)        Yes (check always fails) (2)
- Present, has value False  |    No  (3)        No (4)
- Not present               |    Yes (5)        No (6)

La cosa sorprendente qui è che non viene eseguito alcun controllo se entrambe <SpecificVersion>e le informazioni sulla versione sono assenti (caso 6). Mi sarei aspettato che il controllo venisse eseguito e fallisse sempre (come nel caso 2) perché nella mia comprensione l'assenza di <SpecificVersion>implica il valore predefinito "Vero". Questa potrebbe essere una stranezza di Visual Studio 2010 in cui ho eseguito i miei test.

Quando si esaminano le proprietà di un riferimento di assembly nell'interfaccia utente di Visual Studio (selezionare il riferimento e premere F4), il valore visualizzato per la proprietà "Versione specifica" indica se Visual Studio eseguirà o meno la "Versione specifica" dai un'occhiata. Nel caso 6 l'interfaccia utente mostrerà "True", sebbene l' <SpecificVersion>elemento non sia presente nel file .csproj.

Effetti collaterali su "Copia locale"

Se la proprietà "Copia locale" è impostata su "True" ma il processo di risoluzione dell'assembly non riesce a causa del controllo "Versione specifica", nessun assembly viene copiato.

Materiale di riferimento

• Cosa è necessario sapere sugli assembly referenziati in VS2005 (articolo blogs.msdn.com)
• Novità di .NET 2.0 per assembly e versioning? (articolo codemag.com che riproduce l'articolo MSDN sopra, fino al testo, ma contiene alcuni screenshot e ulteriori informazioni sul controllo delle versioni degli assembly)

Quando si aggiunge un riferimento, Visual Studio registra [AssemblyVersion] dell'assembly nel file di progetto. Questo è importante. Se, ad esempio, creare un bug fix, un anno dopo poi si vuole fare in modo che si ricostruisce il progetto con la esatta stessa versione di riferimento ed è quindi un vero e drop-in. Verrà visualizzato un errore se l'assembly di riferimento è stato modificato.

Ma questo non è sempre desiderabile. Alcuni programmatori consentono alla versione dell'assemblaggio di aumentare automaticamente, generando una nuova versione ogni volta che ricostruiscono. Anche se l'interfaccia pubblica dell'assemblea non è mai cambiata. Alcuni configurano il loro progetto usando Nuget per ottenere librerie e lasciarlo aggiornare automaticamente quando è disponibile una nuova versione. Vorranno impostare la proprietà Versione specifica su False per eliminare l'errore di compilazione.

Abbastanza importante per capire le conseguenze, è necessario ridistribuire l'intera build del programma per evitare incidenti. La versione non corrisponde al crash durante l'esecuzione del programma e può essere eliminata solo con un <bindingRedirect>file .config che è rischioso.