. NET 4.0 tiene un nuevo GAC, ¿por qué?
%windir%\Microsoft.NET\assembly\ es el nuevo GAC. ¿Significa que ahora tenemos que administrar dos GACS, uno para aplicaciones. NET 2.0 - 3.5 y el otro para aplicaciones. NET 4.0?
La pregunta es, ¿por qué?
3 answers
Sí dado que hay 2 Caché 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 por cada CLR.
La versión CLR utilizada tanto para.NET Framework 2.0 como para. NET Framework 3.5 es CLR 2.0. En las dos versiones anteriores del framework no había necesidad de dividir GAC. El problema de romper las aplicaciones más antiguas en Net Framework 4.0.
A evite 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 y cuando sean del mismo CLR. No quieren romper viejas aplicaciones.
Vea la siguiente información en MSDN sobre los cambios GAC en 4.0.
Por ejemplo, si tanto. NET 1.1 como. NET 2.0 comparten el mismo GAC, entonces una aplicación. NET 1.1, cargando un ensamblado 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 ambos. NET Framework 2.0 y. NET Framework 3.5 es CLR 2.0. Como resultado de esto, hay no era necesario en los dos anteriores versiones de framework para dividir el GAC. El problema de romper el viejo (en este case,. NET 2.0) aplicaciones resurge en Net Framework 4.0 en qué punto CLR 4.0 liberado. Ahí, para evitar problemas de interferencia entre CLR 2.0 y CLR 4.0, el GAC es ahora dividido en GACS privados para cada ejecución.
Como el CLR se actualiza en futuras versiones, puede esperar lo mismo. Si solo cambia el idioma, entonces puede utilizar el el mismo GAC.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-13 01:41:02
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 Ensamblaje Global (GAC):
Mark Miller dijo... 28 de junio de 2010 12:13 PM
Gracias por post. "Problemas de interferencia" fue intencionalmente vago. En el momento de escrito, los problemas todavía estaban siendo investigados, pero estaba claro allí fueron varios escenarios rotos.
Por ejemplo, algunas aplicaciones utilizan Assemby.LoadWithPartialName a cargar la versión más alta de una asamblea. Si la versión más alta fue compilada con v4, entonces una aplicación v2 (3.0 o 3.5) podría no cargarlo, y la aplicación se bloquearía, incluso si hubiera una versión que hubiera funcionado. Originalmente, nosotros particionado el GAC bajo su ubicación original, pero que causó algunos problemas con la actualización de Windows escenario. Ambos involucraron código que ya había enviado, así que mover nuestro (versión-particionado GAC a otro lugar.
Esto no debería tener ningún impacto para la mayoría aplicaciones, y no añade ninguna carga de mantenimiento. Ambas ubicaciones solo se debe acceder o modificar uso de las API nativas de GAC, que tratan con la partición como se esperaba. El los lugares donde esto emerge son a través de API que exponen las rutas de el GAC como GetCachePath, o examinando la ruta de mscorlib loaded en código administrado.
Es vale la pena señalar que hemos modificado GAC ubicaciones cuando lanzamos v2 también cuando introdujimos la arquitectura como parte de la identidad de la asamblea. Aquellos se agregaron GAC_MSIL, GAC_32 y GAC_64, aunque todos todavía bajo % windir% \ assembly. Por desgracia, que no era una opción para este lanzamiento.
Espero que ayude a futuros lectores.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-10-05 20:50:19
No tiene mucho sentido, el GAC original ya era bastante capaz de almacenar diferentes versiones de ensamblajes. Y hay pocas razones para asumir que un programa alguna vez hará referencia accidentalmente al ensamblado incorrecto, todos los ensamblados. NET 4 tienen el [AssemblyVersion] subido a 4.0.0.0. La nueva característica de lado a lado en el proceso no debería cambiar esto.
Mi conjetura: ya había demasiados proyectos. NET por ahí que rompió el " nunca hacer referencia a nada en el GAC directamente " regla. Lo he visto en este sitio varias veces.
Solo hay una forma de evitar romper esos proyectos: mover el GAC. Back-compat es sagrado en Microsoft.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-04-18 00:20:17