.NET 4.0 ha un nuovo GAC, perché?

%windir%\Microsoft.NET\assembly\è il nuovo GAC . Significa ora che 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é esistono 2 Global Assembly Cache (GAC) distinti, dovrai gestirli singolarmente.

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

La versione CLR utilizzata per .NET Framework 2.0 e .NET Framework 3.5 è CLR 2.0. Nelle due versioni precedenti del framework non era necessario dividere GAC. Il problema di rompere le applicazioni meno recenti 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. La principale modifica è che le applicazioni CLR v2.0 ora non possono vedere gli assembly CLR v4.0 nel GAC.

fonte

Perché?

Sembra che ci sia stata una modifica CLR in .NET 4.0 ma non in 2.0 a 3.5. La stessa cosa è successa con CLR da 1.1 a 2.0. Sembra che il GAC abbia la capacità di memorizzare versioni diverse 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 sia .NET 1.1 che .NET 2.0 condividevano lo stesso GAC, un'applicazione .NET 1.1, caricando un assembly da questo GAC condiviso, poteva ottenere assembly .NET 2.0, interrompendo così l'applicazione .NET 1.1

La versione CLR utilizzata per .NET Framework 2.0 e .NET Framework 3.5 è CLR 2.0. Di conseguenza, nelle due versioni precedenti del framework non era necessario dividere il GAC. Il problema di rompere le applicazioni meno recenti (in questo caso .NET 2.0) riappare in Net Framework 4.0, a quel punto è stato rilasciato CLR 4.0. Pertanto, per evitare problemi di interferenza tra CLR 2.0 e CLR 4.0, il GAC è ora suddiviso in GAC privati ​​per ogni runtime.

Poiché il CLR verrà 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 12:13 PM

Grazie per il post. "Problemi di interferenza" era intenzionalmente vago. Al momento della stesura del presente documento, i problemi erano ancora oggetto 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 v4, quindi un'app v2 (3.0 o 3.5) non è in grado di caricarla e l'app si arresterebbe in modo anomalo, anche se esistesse una versione che avrebbe funzionato. Inizialmente, abbiamo partizionato il GAC nella sua posizione originale, ma ciò ha causato alcuni problemi con gli scenari di aggiornamento di Windows. Entrambi riguardavano il codice che era già stato spedito, quindi abbiamo spostato il nostro (GAC partizionato in versione in un altro posto.

Ciò non dovrebbe avere alcun impatto sulla maggior parte delle applicazioni e non aggiunge alcun onere di manutenzione. È possibile accedere o modificare entrambe le posizioni solo tramite le API GAC native, che gestiscono il partizionamento come previsto. I luoghi in cui ciò emerge sono tramite 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 anche quando abbiamo rilasciato v2 quando abbiamo introdotto l'architettura come parte dell'identità dell'assembly. Quelli hanno aggiunto GAC_MSIL, GAC_32 e GAC_64, sebbene tutti ancora sotto% 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 in grado di memorizzare diverse versioni di assiemi. E ci sono pochi motivi per presumere che un programma possa mai fare riferimento accidentalmente all'assembly sbagliato, tutti gli assembly .NET 4 hanno ottenuto che [AssemblyVersion] sia stato bloccato fino alla 4.0.0.0. La nuova funzionalità side-by-side in-process non dovrebbe cambiarla.

La mia ipotesi: c'erano già troppi progetti .NET là fuori che hanno infranto la regola "mai fare riferimento direttamente a GAC". L'ho visto fare su questo sito diverse volte.

Un solo modo per evitare di interrompere quei progetti: spostare il GAC. Back-compat è sacro in Microsoft.