2008-08-22 37 views

Respuesta

3

En toda mi vida, he tenido quizás una aplicación en la que tuve que montar un ensamblaje en el GAC, simplemente porque estos ensamblajes formaban parte de un marco que varias aplicaciones usarían, y parecía correcto ponerlo ellos en el GAC.

6

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)

43
  • Cargando asambleas de GAC significan menos gastos generales y la seguridad de que su aplicación siempre se cargarán versión correcta de la biblioteca .NET
  • No debe ngen asambleas que están fuera del GAC, porque no habrá casi ninguna mejora del rendimiento , en muchos casos, incluso pérdida de rendimiento.
  • Ya está utilizando GAC, porque todos los ensamblados .NET estándar están realmente en GAC y ngened (durante la instalación).
  • El uso de GAC para sus propias bibliotecas agrega complejidad a la implementación, yo trataría de evitarlo a toda costa.
  • Sus usuarios deben registrarse como administradores durante la instalación si desea poner algo en GAC, un problema bastante grande para muchos tipos de aplicaciones.

Por lo tanto, para resumirlo todo, comience de manera simple y si luego observa mejoras importantes en el rendimiento si coloca los ensamblajes en GAC y los NGEN, prosiga, 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.

+0

En cuanto a su segundo punto, ¿por qué es este el caso? – Sam

+2

@Sam: compruebe http://msdn.microsoft.com/en-us/magazine/cc163610.aspx, en particular, la sección "Ensambles y el GAC" –

18

Ventaja:

  • Sólo un lugar para actualizar sus assemblys
  • Se utiliza un poco de espacio en el disco menos duro

Desventaja:

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

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

6

GAC funciona con plena confianza y puede ser utilizado por aplicaciones fuera de 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 pieza "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 tiene un post on CAS as well que detalla las diferencias un poco más.

18

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, Confianza total. 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 privilegiada está marcado con el atributo PermissionSet, algo como esto:

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

Nuestra asamblea se le daría un nombre seguro (firmado) y luego desplegado 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.

7

Si envía 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.

Imagínese, envía 6 conjuntos, y solo uno de estos 6 conjuntos contiene una fachada, es decir, otros 5 solo los utiliza la fachada. Realizan envíos:

  • MyProduct.Facade.dll - que 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 utilizados por MyProduct.Component1.dll
  • ThirdParty.Lib2.dll - el mismo
  • etc.

Los desarrolladores que utilizan su proyecto les gustaría para hacer referencia simplemente 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 ya sea en la carpeta Bin, el GAC en:

  • Usted puede pedir a los desarrolladores para localizar la carpeta de instalación y agregar referencias a todos los N asambleas que se pone ahí. Esto asegurará que se copien en la carpeta Bin para que esté disponible en tiempo de ejecución.
  • Puede instalar la plantilla de proyecto VS.NET que ya contiene estas 6 referencias. Un poco complejo, ya que debe inyectar la ruta real a sus ensambles 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 crear un paso especial posterior a la compilación en el archivo .csproj/.vbproj copiando las dependencias necesarias a la carpeta Bin. Las mismas desventajas.
  • Finalmente, puede instalar todos sus ensambles 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.

Por lo que la solución descrita muestra la ventaja de poner conjuntos 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;)

+0

Esto es bueno. Reeeaaaal agradable. Estamos utilizando un compilador de terceros .NET de COBOL que compila un .dll y luego llama al .dll de terceros al que intentamos llamar desde VB6, agregando solo la referencia que creamos, no la de terceros. Si no hubiera leído esto, nunca lo hubiera pensado. – GibralterTop

Cuestiones relacionadas