.NET 4.0 ha un nuovo GAC, perché?

%windir%\Microsoft.NET\assembly\ è il nuovo GAC . Significa che ora dobbiamo gestire due GAC, uno per le applicazioni .NET 2.0-3.5 e l’altro per le applicazioni .NET 4.0?

La domanda è, perché?

Sì poiché ci sono 2 distinte Global Assembly Cache (GAC), dovrai gestirle singolarmente.

In .NET Framework 4.0, il GAC ha subito alcune modifiche. Il GAC è stato diviso in due, uno per ogni CLR.

La versione CLR utilizzata per .NET Framework 2.0 e .NET Framework 3.5 è CLR 2.0. Nei due precedenti rilasci di framework non era necessario dividere GAC. Il problema di rompere le vecchie applicazioni in Net Framework 4.0.

Per evitare problemi tra CLR 2.0 e CLR 4.0, il GAC è ora suddiviso in GAC privati ​​per ogni runtime. Il cambiamento principale è che le applicazioni CLR v2.0 non possono ora vedere gli assembly CLR v4.0 nel GAC.

fonte

Perché?

Sembra che ci sia stato un cambiamento CLR in .NET 4.0 ma non nella versione da 2.0 a 3.5. La stessa cosa è accaduta con 1.1 a 2.0 CLR. Sembra che il GAC abbia la possibilità di memorizzare diverse versioni di assiemi purché provengano dallo stesso CLR. Non vogliono rompere le vecchie applicazioni.

Vedere le seguenti informazioni in MSDN sulle modifiche GAC in 4.0 .

Ad esempio, se entrambi .NET 1.1 e .NET 2.0 condividevano lo stesso GAC, un’applicazione .NET 1.1, caricando un assembly da questo GAC condiviso, poteva ottenere gli assembly .NET 2.0, interrompendo in tal modo l’applicazione .NET 1.1.

La versione CLR utilizzata per .NET Framework 2.0 e .NET Framework 3.5 è CLR 2.0. Di conseguenza, nei due precedenti rilasci di framework non era necessario dividere il GAC. Il problema di rompere le vecchie (in questo caso, .NET 2.0) le applicazioni riemerge in Net Framework 4.0 a quel punto rilasciato CLR 4.0. Quindi, per evitare problemi di interferenza tra CLR 2.0 e CLR 4.0, il GAC è ora suddiviso in GAC privati ​​per ciascun runtime.

Poiché il CLR viene aggiornato nelle versioni future, puoi aspettarti la stessa cosa. Se cambia solo la lingua, puoi utilizzare lo stesso GAC.

Volevo anche sapere perché 2 GAC e ho trovato la seguente spiegazione di Mark Miller nella sezione commenti di .NET 4.0 ha 2 Global Assembly Cache (GAC) :

Mark Miller ha detto … 28 giugno 2010 alle 12:13

Grazie per il post. Le “questioni di interferenza” erano intenzionalmente vaghe. Al momento della scrittura, i problemi erano ancora object di indagine, ma era chiaro che c’erano diversi scenari rotti.

Ad esempio, alcune applicazioni utilizzano Assemby.LoadWithPartialName per caricare la versione più alta di un assembly. Se la versione più alta è stata compilata con la v4, allora un’app v2 (3.0 o 3.5) non è stata in grado di caricarla e l’app si arresterebbe in modo anomalo, anche se ci fosse una versione che avrebbe funzionato. Inizialmente, abbiamo suddiviso il GAC sotto la sua posizione originale, ma ciò ha causato alcuni problemi con gli scenari di aggiornamento di Windows. Entrambi i codici coinvolti erano già stati spediti, quindi abbiamo spostato il nostro GAC con versione partizionata in un altro posto.

Ciò non dovrebbe avere alcun impatto sulla maggior parte delle applicazioni e non aggiunge alcun onere di manutenzione. Entrambe le posizioni dovrebbero essere accessibili o modificate solo utilizzando le API GAC native, che trattano il partizionamento come previsto. Le aree in cui viene eseguita questa operazione sono le API che espongono i percorsi del GAC come GetCachePath o esaminano il percorso di mscorlib caricato nel codice gestito.

Vale la pena notare che abbiamo modificato le posizioni GAC quando abbiamo rilasciato anche v2 quando abbiamo introdotto l’architettura come parte dell’identity framework dell’assembly. Quelli aggiunti GAC_MSIL, GAC_32 e GAC_64, anche se tutti ancora in% windir% \ assembly. Sfortunatamente, questa non era un’opzione per questa versione.

Spero che aiuti i futuri lettori.

Non ha molto senso, il GAC originale era già abbastanza capace di memorizzare diverse versioni di assiemi. E ci sono pochi motivi per ritenere che un programma possa mai accidentalmente fare riferimento all’assembly sbagliato, tutti gli assemblati .NET 4 hanno fatto il [AssemblyVersion] urtato fino alla 4.0.0.0. La nuova funzionalità side-by-side in-process non dovrebbe cambiare questo.

La mia ipotesi: c’erano già troppi progetti .NET là fuori che hanno infranto la regola “non fare mai riferimento a nulla nella GAC ​​direttamente”. L’ho visto fare più volte su questo sito.

Solo un modo per evitare di rompere quei progetti: spostare il GAC. Back-compat è sacro in Microsoft.