.NET 4.0 tiene un nuevo GAC, ¿por qué?

%windir%\Microsoft.NET\assembly\ es el nuevo GAC . ¿Significa ahora que tenemos que administrar dos GAC, uno para aplicaciones .NET 2.0-3.5 y el otro para aplicaciones .NET 4.0?

La pregunta es, ¿por qué?

Sí, ya que hay 2 Caché de Asamblea Global (GAC) distintas, tendrá que administrar cada una de ellas individualmente.

En .NET Framework 4.0, el GAC realizó algunos cambios. El GAC se dividió en dos, uno para cada CLR.

La versión CLR utilizada para .NET Framework 2.0 y .NET Framework 3.5 es CLR 2.0. No hubo necesidad en los dos lanzamientos anteriores del marco para dividir el GAC. El problema de romper aplicaciones antiguas en Net Framework 4.0.

Para evitar problemas entre CLR 2.0 y CLR 4.0, el GAC ahora se divide en GAC privados para cada tiempo de ejecución. El principal cambio es que las aplicaciones de CLR v2.0 ahora no pueden ver los ensamblados de CLR v4.0 en el GAC.

Fuente

¿Por qué?

Parece ser porque hubo un cambio de CLR en .NET 4.0 pero no en 2.0 a 3.5. Lo mismo sucedió con 1.1 a 2.0 CLR. Parece que el GAC tiene la capacidad de almacenar diferentes versiones de ensamblajes siempre que sean del mismo CLR. No quieren romper aplicaciones viejas.

Consulte la siguiente información en MSDN sobre los cambios del GAC en 4.0 .

Por ejemplo, si tanto .NET 1.1 como .NET 2.0 compartían el mismo GAC, entonces una aplicación .NET 1.1, cargando un ensamblaje desde este GAC compartido, podría obtener ensamblados .NET 2.0, rompiendo así la aplicación .NET 1.1.

La versión CLR utilizada para .NET Framework 2.0 y .NET Framework 3.5 es CLR 2.0. Como resultado de esto, no hubo necesidad en los dos lanzamientos anteriores del marco para dividir el GAC. El problema de romper aplicaciones antiguas (en este caso, .NET 2.0) resurge en Net Framework 4.0 y en ese momento se lanzó CLR 4.0. Por lo tanto, para evitar problemas de interferencia entre CLR 2.0 y CLR 4.0, el GAC ahora se divide en GAC privados para cada tiempo de ejecución.

Como el CLR se actualiza en versiones futuras, puede esperar lo mismo. Si solo cambia el idioma, puede usar el mismo GAC.

También quería saber por qué 2 GAC y encontré la siguiente explicación de Mark Miller en la sección de comentarios de .NET 4.0 tiene 2 Caché de Asamblea Global (GAC) :

Mark Miller dijo … 28 de junio 2010 12:13 PM

Gracias por la publicacion. “Problemas de interferencia” fue intencionalmente vago. En el momento de escribir, los problemas aún se estaban investigando, pero estaba claro que había varios escenarios rotos.

Por ejemplo, algunas aplicaciones usan Assemby.LoadWithPartialName para cargar la versión más alta de un ensamblaje. Si la versión más alta se compiló con v4, una aplicación v2 (3.0 o 3.5) no podría cargarla, y la aplicación fallaría, incluso si hubiera una versión que hubiera funcionado. Originalmente, dividimos el GAC en su ubicación original, pero eso causó algunos problemas con los escenarios de actualización de Windows. Ambos códigos implicados que ya se habían enviado, por lo que trasladamos nuestro (GAC con partición de versión a otro lugar.

Esto no debería tener ningún impacto en la mayoría de las aplicaciones, y no agrega ninguna carga de mantenimiento. Ambas ubicaciones solo se deben acceder o modificar utilizando las API nativas del GAC, que se ocupan de la partición como se espera. Los lugares donde esto sale a la superficie son a través de API que exponen las rutas del GAC, como GetCachePath, o examinando la ruta de mscorlib cargada en el código administrado.

Vale la pena señalar que modificamos las ubicaciones de GAC cuando lanzamos v2 también cuando introdujimos la architecture como parte de la identidad del ensamblado. Aquellos agregaron GAC_MSIL, GAC_32 y GAC_64, aunque todos siguen en% windir% \ assembly. Desafortunadamente, esa no era una opción para este lanzamiento.

Espero que ayude a los lectores futuros.

No tiene mucho sentido, el GAC original ya era bastante capaz de almacenar diferentes versiones de ensamblajes. Y hay pocas razones para suponer que un progtwig alguna vez haga referencia accidentalmente al ensamblado incorrecto, todos los ensamblados .NET 4 obtuvieron el [AssemblyVersion] ejecutado hasta 4.0.0.0. La nueva característica en proceso lado a lado no debería cambiar esto.

Mi suposición: ya había demasiados proyectos .NET que rompieron la regla de “nunca hacer referencia a nada en el GAC directamente”. Lo he visto hecho en este sitio varias veces.

Solo una forma de evitar romper esos proyectos: mover el GAC. Back-compat es sagrado en Microsoft.