¿Cuándo debería implementar mis ensamblajes en el GAC?

Me gustaría saber prácticamente qué tipo de ensambles debo implementar en GAC.

Caso 1 : si en mi solución, el proyecto múltiple usa log4net.dll, ¿debería implementarse en GAC?

Caso 2 : si tengo varias aplicaciones implementadas en una máquina, cada una de las cuales usa log4net.dll es la razón suficiente para implementar log4net.dll en GAC.

Pregunta: ¿Cuándo debería implementar mis ensamblajes en el GAC?

Respuesta: Nunca

Respuesta real, honesta, real: casi nunca

Discusión

Solo deje caer cosas en el GAC cuando varias aplicaciones de la máquina usen el ensamblado y cuando el ensamblaje sea fundamental (es probable que lo utilicen varias aplicaciones), cuando se firme y cuando casi nunca se actualice ese ensamblaje. Tal vez agregar eso, cuando tener múltiples versiones independientes de un DLL implementado con cada aplicación en realidad sería perjudicial.

Un ejemplo de esto último es: supongamos que tiene 2 aplicaciones independientes, desarrolladas independientemente y desplegadas de forma independiente. Sin embargo, existe la posibilidad de que se intercomuniquen. Intercambiarán … algo … por .NET Remoting en la máquina local. Si tiene un único ensamblaje en el GAC, estas aplicaciones tienen la seguridad de que la intercomunicación solo funcionará. Sin embargo, si cada uno de ellos tiene una versión separada de un ensamblaje, es posible que no puedan intercambiar objetos. Es una ocurrencia tan rara que probablemente no la necesite. Si no estás seguro, entonces no lo necesitas.


El escenario GAC base es la biblioteca de clases base .NET. Estos ensamblados son enviados por Microsoft. Ellos son autoritativos. Ellos son fundamentales y firmado Raramente cambian. Todas las aplicaciones deben usar las mismas copias de esas DLL. Por lo tanto, pertenecen al GAC.

Por el contrario, las DLL de su aplicación no son de Microsoft, no son fundamentales, y probablemente no estén firmadas. Cambian más a menudo, y solo hay algunas aplicaciones (¡tal vez una sola!) Que usan cada DLL. Sin GAC.


Podría imaginarme un dispositivo de hardware, digamos una cámara digital, que instala un ensamblado .NET para permitir la progtwigbilidad. Ese es un escenario donde la asamblea podría encajar bien en el GAC. Permite que las aplicaciones .NET arbitrarias accedan a la cámara digital mediante progtwigción.


Su ejemplo de log4net no es, en mi opinión, suficiente para justificar la instalación del ensamblado en el GAC. Imagine el escenario en el que una de las aplicaciones obtiene una actualización y, como parte de la actualización, utiliza una nueva versión de log4net. ¿Ahora que? ¿Debería colocarse el nuevo ensamblaje de log4net en el GAC? Probablemente no.

La idea de compartir archivos DLL entre aplicaciones se basaba en la premisa de que la memoria y el almacenamiento en disco eran escasos. Érase una vez, eso fue cierto. No es verdad, por más tiempo. En caso de duda, no use el GAC.

el log4net.dll tiene un tamaño de 95 KB. incluso si lo despliega 100 veces, realmente no importaría con los discos duros de hoy. Trato de evitar el GAC siempre que sea posible por varias razones:

  • hace que la implementación sea más difícil, debe decirle al instalador qué debe poner en el GAC. Me gusta la posibilidad de crear configuraciones de xcopy simples (copiar un directorio para instalar, eliminarlo para desinstalar). porque eso es simple, pero no funciona tan bien tan pronto como tenga que poner cosas en el GAC.
  • tienes que firmar tus asambleas. solo para meterlos en el GAC …
  • En cuanto un desarrollador hace referencia a algo del GAC en su proyecto de estudio visual, la referencia se perderá cuando otro desarrollador abra la solución en su PC. Primero tendrá que obtener las asambleas necesarias en el GAC antes de que pueda abrir y comstackr la solución. ese es un PITA real Quiero poder pagar, comstackr y ejecutar sin errores.

El único tipo de asamblea que debería considerar incluir en el GAC es una asamblea madura y estable. En el caso de log4net, si está satisfecho de que la versión que tiene es estable, madura y no es probable que cambie esa versión pronto, siéntase libre de incluirla en el GAC.

No intente colocar bibliotecas en el GAC que puedan cambiar, especialmente si las está desarrollando internamente y todavía hay margen para mejoras adicionales. Impleméntalos como conjuntos privados en su lugar.

He visto personas evangelizar la maravilla del código compartido. Dicen cosas como “ah, mejoraremos 20 aplicaciones al mismo tiempo con este cambio de código”. El problema es que también puedes destruir 20 aplicaciones al mismo tiempo si te equivocas. He visto a personas decir: “Acabo de lanzar el sitio X. ¿Pueden verificar los sitios AW para asegurarse de que todavía funcionen?”.

Los ensamblajes privados pueden ser un problema, pero los problemas que podría enfrentar se limitan a la aplicación específica contra la que se implementan. Si no está 100% seguro de que un ensamblaje no es estable y está maduro, no lo coloque en el GAC.

Créeme, dormirás mejor.

Lo que describes es una situación lo suficientemente decente como para poner una asamblea en el GAC. A decir verdad, lo evitaría. Con el GAC, debe preocuparse por el buen nombre y confiabilidad de los ensamblajes y las versiones de ensamblaje específicas. Si no tienes un motivo explícito para necesitarlos. Es igual de fácil implementar el dll varias veces para cada proyecto.

Sé que esto va en contra de almacenar copias múltiples del mismo código, etc., pero siempre me ha resultado más fácil simplemente evitar el uso del GAC. Cuando lo he usado, el GAC siempre ha sido problemático, porque debe preocuparse si el GAC tiene todos los ensamblajes correctos para el proyecto (porque los ensamblados pueden hacer referencia a otros ensamblajes). Cuando no usa el GAC, es mucho más fácil ir, “¿Están allí las asambleas?” “Sí, están en la carpeta de aplicaciones”.

La única vez que lo encontré útil fue cuando tuve que crear SharePoint Services WSS 2.0. Me encontré con un momento en el que actualizar la sección de configuración para permitir la confianza era engorroso (debido a la política corporativa) y colocarlo en el GAC para permitirle confiar plenamente no lo era. Este fue un caso muy raro.