Me gustaría saber prácticamente qué tipo de ensambles debo implementar en GAC.¿Cuándo debo implementar mis ensamblajes en el GAC?
Caso 1: Si en mi solución el proyecto múltiple usa log4net.dll, ¿debería desplegarse en GAC?
Caso 2: Si tengo implementada una aplicación múltiple 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 debo implementar mis ensamblajes en el GAC?
Respuesta: Nunca
real, honesto, respuesta real: Casi nunca
Discusión
de Salto a las cosas en la GAC cuando múltiples aplicaciones en la máquina utilizará la ensamblado, y cuando el ensamblaje es fundamental (es probable que lo utilicen varias aplicaciones), cuando está firmado y cuando casi no se espera que 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. Esto es tan raro que probablemente no lo necesite. Si no estás seguro, entonces no lo necesitas.
El escenario GAC base es la biblioteca de clases de .NET Base. 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, su DLL de aplicación no son de Microsoft, no son fundamentales, y probablemente no se hayan firmado. Cambian más a menudo, y solo hay algunas aplicaciones (¡tal vez una sola!) Que usan cada DLL. Sin GAC.
me podría imaginar un dispositivo de hardware, digamos que una cámara digital, que se instala un ensamblado de .NET para permitir la programación. 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 programación.
Su ejemplo log4net no es, en mi opinión, lo suficiente como para justificar poner el ensamblado en la 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.
Toda 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.
Lo que usted describe es una situación lo suficientemente decente como para colocar un ensamblaje 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 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.
El único tipo de ensamblaje que debe considerar colocar en el GAC es un ensamblaje maduro 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 a gente 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 A-W para asegurarse de que todavía funcionen?".
Los ensamblados privados pueden ser un problema, pero los problemas que puede 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.
Confíe en mí, dormirá mejor.
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:
+1 - ¡Odio ** esa "característica" de referencia de GAC de Visual Studio !! – TrueWill
+1 Cuando se empieza con.NET pensamos que poner nuestras asambleas marco en el GAC era lo correcto. Estuvimos equivocados. Esto complica las cosas tanto para los desarrolladores como para las instalaciones de control de calidad y de los clientes. Para obtener los beneficios de las versiones paralelas del mismo ensamblaje en el GAC, debe definir explícitamente los números de versión en los archivos de configuración, que es un verdadero P.I.T.A para todos. Simplemente no lo hagas. – si618
Estoy de acuerdo. Estamos atrapados con algunas bibliotecas en nuestro GAC y realmente es un problema, no solo para el desarrollo sino también para la implementación, porque necesita la administración directamente en el servidor de producción para instalar cosas en el GAC y no siempre es posible. –
Oh Dios mío ODIO el gac. +1 para la primera línea de esta respuesta. –