versiones - .NET 4.0 tiene un nuevo GAC, ¿por qué?
que net framework debo instalar en windows 7 (3)
%windir%/Microsoft.NET/assembly/ es el nuevo GAC . ¿Significa que ahora tenemos que administrar dos GAC, uno para aplicaciones .NET 2.0-3.5 y otro para aplicaciones .NET 4.0?
La pregunta es, ¿por qué?
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 programa hará referencia accidentalmente al ensamblaje incorrecto, todos los ensamblados .NET 4 lograron que la [AssemblyVersion] se subiera a 4.0.0.0. La nueva función lado a lado en el proceso no debería cambiar esto.
Mi conjetura: 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.
Una sola manera de evitar romper esos proyectos: mover el GAC. Back-compat es sagrado en Microsoft.
Sí, ya que hay 2 cachés de ensamblaje global (GAC) distintos, tendrá que administrar cada uno de ellos individualmente.
En .NET Framework 4.0, el GAC pasó por algunos cambios. El GAC se dividió en dos, uno para cada CLR.
La versión de CLR utilizada para .NET Framework 2.0 y .NET Framework 3.5 es CLR 2.0. No había necesidad en los dos lanzamientos anteriores 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 cambio principal es que las aplicaciones CLR v2.0 ahora no pueden ver los ensamblados CLR v4.0 en el GAC.
¿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 viejas aplicaciones.
Consulte la siguiente información en MSDN sobre los cambios de 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, al cargar un ensamblado desde este GAC compartido, podría obtener los ensamblados .NET 2.0, rompiendo así la aplicación .NET 1.1
La versión de 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 para dividir el GAC. El problema de romper aplicaciones más antiguas (en este caso, .NET 2.0) reaparece en Net Framework 4.0, momento en el que 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 futuras versiones, 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 ensamblados global (GAC) :
Mark Miller dijo ... 28 de junio 2010 12:13 PM
Gracias por la publicacion. Los "problemas de interferencia" eran intencionalmente vagos. Al momento de escribir este artículo, los problemas aún estaban siendo investigados, 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, entonces una aplicación v2 (3.0 o 3.5) no podría cargarla y la aplicación se bloquearí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 incluían el código que ya se había enviado, por lo que trasladamos nuestro (GAC con particiones 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. Solo se debe acceder o modificar a ambas ubicaciones utilizando las API de GAC nativas, que se ocupan de la partición como se esperaba. Los lugares en los que esto se manifiesta son las API que exponen las rutas de acceso del GAC, como GetCachePath, o el examen de la ruta de mscorlib cargada en el código administrado.
Vale la pena señalar que modificamos las ubicaciones de GAC cuando lanzamos v2 y cuando introdujimos la arquitectura como parte de la identidad del ensamblado. Los agregados GAC_MSIL, GAC_32 y GAC_64, aunque todos aún están bajo% windir% / assembly. Desafortunadamente, esa no era una opción para este lanzamiento.
Espero que ayude a futuros lectores.