¿Cuáles son las ventajas y desventajas de usar el GAC?

Y además de eso, ¿hay casos en los que uno tiene que usar el caché de ensamblaje global o donde uno no puede usarlo?

  • La carga de ensamblados desde GAC significa menos sobrecarga y seguridad de que su aplicación siempre cargará la versión correcta de la biblioteca .NET
  • No debe agregar ensamblados que estén fuera de GAC, ya que casi no habrá ganancia de rendimiento, en muchos casos, incluso se perderá el rendimiento.
  • Ya está utilizando GAC, porque todos los ensamblados de .NET estándar están realmente en GAC y ngened (durante la instalación).
  • Usar GAC para sus propias bibliotecas agrega complejidad a la implementación, trataría de evitarlo a toda costa.
  • Sus usuarios deben registrarse como administradores durante la instalación si desea incluir algo en GAC, un problema bastante común para muchos tipos de aplicaciones.

Así que, para resumirlo todo, comience de manera simple y si más tarde observa mayores ganancias de rendimiento si coloca sus ensamblajes en GAC y los NGEN, avance, de lo contrario no se moleste. GAC es más adecuado para los marcos donde se espera que la biblioteca se comparta entre más aplicaciones, en el 99% de los casos, no la necesita.

Ventaja:

  • Solo un lugar para actualizar sus ensambles
  • Utiliza un poco menos de espacio en el disco duro

Desventaja:

  • Si necesita actualizar solo un sitio web, no puede. Puede terminar con los otros sitios web en el servidor web roto

Recomendación: dejar el GAC a MS y amigos. El gigabyte es muy barato ahora.

El GAC también puede ser utilizado por ensamblados que requieren permisos elevados para realizar operaciones privilegiadas en nombre de un código menos confiable (por ejemplo, una aplicación ASP.NET de confianza parcial).

Por ejemplo, supongamos que tiene una aplicación ASP.NET de confianza parcial que necesita realizar una tarea que requeriría privilegios elevados, es decir, plena confianza . La solución es colocar el código que requiere privilegios elevados en un ensamblaje separado. El conjunto está marcado con el atributo AllowPartiallyTrustedCallers y la clase que contiene la lógica con privilegios se marca con el atributo PermissionSet, algo como esto:

 [PermissionSet(SecurityAction.Assert, Unrestricted=true)] 

Nuestra asamblea recibiría un nombre fuerte (firmado) y luego se desplegaría en el GAC.

Ahora, nuestra (s) aplicación (es) parcialmente confiable (s) pueden utilizar el ensamblaje de confianza en el GAC para llevar a cabo un conjunto específico y estrecho de operaciones privilegiadas sin perder los beneficios de la confianza parcial.

Cuando investigué este tema yo mismo, descubrí que Desmitificar el caché de ensamblados global de .NET por Jeremiah Talkar me ayudó mucho.

Si está enviando una biblioteca reutilizable que consta de varios ensamblajes, pero solo unos pocos forman una fachada, puede considerar instalar los ensamblajes en GAC, si el paquete está instalado en las PC del desarrollador.

Imagine que envía 6 conjuntos y solo uno de estos 6 conjuntos contiene una fachada, es decir, otros 5 solo los utiliza la fachada. Usted envía:

  • MyProduct.Facade.dll : ese es el único componente destinado a ser utilizado por los desarrolladores
  • MyProduct.Core.dll: utilizado por MyProduct.Facade.dll, pero no destinado a ser utilizado por los desarrolladores
  • MyProduct.Component1.dll: el mismo
  • MyProduct.Component2.dll: el mismo
  • ThirdParty.Lib1.dll – biblioteca de terceros utilizada por MyProduct.Component1.dll
  • ThirdParty.Lib2.dll: el mismo
  • etc.

Los desarrolladores que usan su proyecto desean hacer referencia solo a MyProduct.Facade.dll en sus propios proyectos. Pero cuando se ejecuta su proyecto, debe poder cargar todos los ensamblajes a los que hace referencia, recursivamente. ¿Cómo se puede lograr esto? En general, deben estar disponibles en la carpeta Bin, en GAC:

  • Puede solicitar a los desarrolladores que localicen su carpeta de instalación y añadan referencias a todos los ensamblajes N que coloque allí. Esto asegurará que se copien en la carpeta Bin para que esté disponible en tiempo de ejecución.
  • Puede instalar la plantilla del proyecto VS.NET que ya contiene estas 6 referencias . Un poco complejo, ya que debe inyectar la ruta real a sus ensamblajes en esta plantilla antes de su instalación. Esto solo puede hacerlo el instalador, ya que esta ruta depende de la ruta de instalación.
  • Puede solicitar a los desarrolladores que creen un paso especial posterior a la comstackción en el archivo .csproj / .vbproj copiando las dependencias necesarias a la carpeta Bin. Las mismas desventajas.
  • Finalmente, puede instalar todos sus ensamblajes en GAC . En este caso, los desarrolladores deben agregar la referencia solo a MyProduct.Facade.dll de su proyecto. Todo lo demás estará disponible en tiempo de ejecución de todos modos.

Nota: la última opción no hace que haga lo mismo mientras envía el proyecto a las PC de producción. Puede enviar todos los ensamblajes dentro de la carpeta Bin o instalarlos en GAC, todo depende de su deseo.

Entonces, la solución descrita muestra la ventaja de incluir ensamblajes de terceros en GAC durante el desarrollo. No está relacionado con la producción.

Como puede encontrar, la instalación en GAC está destinada principalmente a resolver el problema de la ubicación de los ensamblajes necesarios (dependencias). Si se instala un ensamblaje en GAC, puede considerar que existe “cerca” de cualquier aplicación. Es como agregar una ruta a .exe a su variable PATH, pero en “forma gestionada”. – por supuesto, esta es una descripción bastante simplificada;)

Creo que una de las mayores ventajas del uso del GAC es que puede tener múltiples versiones del mismo conjunto registradas y disponibles para sus aplicaciones. Personalmente, no me gusta cómo restringe el movimiento de una máquina a otra (no me gusta tener que decir, reviso la fuente en una nueva VPC y paso por varios pasos para que funcione porque tengo que registrar cosas en el GAC)

El GAC funciona con plena confianza y puede ser utilizado por aplicaciones externas a su aplicación web. Por ejemplo, los trabajos de temporizador en Sharepoint TIENEN que estar en el GAC porque el servicio de Sptimer es un proceso separado.

La parte “Full Trust” también es una posible fuente de problemas de seguridad. Claro, puede trabajar con Code Access Security, pero no veo demasiados ensambles que usan CAS desafortunadamente 🙁 La carpeta / bin se puede bloquear en Medium, que normalmente está bien.

Daniel Larson también tiene una publicación en CAS que detalla las diferencias un poco más.

En toda mi vida, tuve quizás una aplicación en la que tuve que montar una asamblea en el GAC, simplemente porque estas asambleas formaban parte de un marco que varias aplicaciones usarían, y parecía correcto incluirlas en el GAC. .