.net - register - ¿Cuándo y cuándo no instalar en el GAC?

register dll in gac windows 10

Question

¿Cuándo debería instalar en el GAC y cuándo no? (Me refiero, realmente, a la instalación en la máquina de un cliente cuando han comprado nuestros productos).

1. Tengo un conjunto que solo se usará con mi única aplicación (GAC o sin GAC).

2. Tengo un ensamblaje que todas mis aplicaciones comparten (GAC o no-GAC)?

3. ¿Todas mis aplicaciones pueden usar diferentes versiones de mi ensamblaje (GAC o no GAC)?

Estos son tres escenarios ... pero estoy seguro de que hay más. No estoy buscando necesariamente una respuesta solo a estas tres preguntas.

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

Answer 1

Aquí está el enlace de Chris Sells llamado "Evita el GAC"

https://sellsbrothers.com/12503

La explicación es bastante larga, pero en resumen, los dos casos que identifica son

1. Soluciona errores críticos sin tocar las aplicaciones afectadas (¡y sin romper nada!)

2. Tipos de intercambio en tiempo de ejecución entre ensamblados desplegados por separado

Nota: Hay un hilo de discusión muy largo al final de la publicación de Chris , muy buena lista de comentarios.

Answer 2

Casos útiles para GAC:

• Código COM-invocable, es decir, desea que algún código que no sea .NET pueda acceder a usted sin interferir con dlls, etc.
• Componentes con servicio (COM +)
• Si está escribiendo código que es tan común, en realidad es significativo usar GAC, principalmente componentes de .NET framework, etc.
• Si quieres usar NGEN para pre-JIT el código

Aparte de eso, tiendo a evitar el GAC como la peste. Es mucho más fácil implementar los dlls necesarios con su aplicación a través de robocopy etc. esto da aislamiento y fácil implementación.

Answer 3

Directrices generales de MS

1. no
2. no
3. no

GAC es realmente un repositorio para las bibliotecas .NET comunes de Microsoft. Sí, también permiten que los desarrolladores lo utilicen, pero como regla general, si no necesita GAC, no lo use. mantenga las cosas simples y locales si no duele.

• Consideraría GAC ​​solo por motivos de rendimiento, por ejemplo, si tiene algunas grandes asambleas, intente colocarlas en GAC y NGEN ellas. Debe aumentar significativamente el rendimiento. Microsoft lo hace para todos los ensamblados de .NET Framework estándar durante la instalación (ahora usted sabe por qué esa instalación lleva tanto tiempo). Paint.NET también lo hace (para mejorar el tiempo de inicio de su aplicación). Sin embargo, la mayoría de nosotros no trabajamos en enormes frameworks o competidores de Photoshop, por lo que la mayoría de las veces, el rendimiento obtenido al tener un ensamblado en GAC es mínimo. No vale la pena abandonar la simple implementación de x-copy.

• Algunos desarrolladores pueden usar GAC para asegurarse de que los usuarios con privilegios insuficientes no puedan eliminar o modificar sus ensamblajes.

• Para otros podría ser por razones de versión, pero aquí realmente debería reconsiderar. No voy a repetir lo que ya se dijo, puedes leer aquí por qué .

Y no olvide que una vez que desee implementar en GAC, su instalador necesitará privilegios de administrador, puede olvidar la implementación de hacer clic una vez, etc.

Answer 4

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 compilació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;)

Answer 5

Si está instalando aplicaciones web asp.net y usted es el propietario y tiene el control total sobre la máquina, entonces en algunos casos podría tener sentido colocar sus ensamblajes, que planea compartir en instancias web / sitios en la caché de ensamblados global.

Podría mejorar drásticamente el tiempo de carga inicial y el uso de memoria de la aplicación en servidores que tienen muchas instancias múltiples de las mismas aplicaciones ASP.NET si coloca los ensamblados en el GAC. Al menos vi esto en nuestros servidores con docenas de instalaciones.

Answer 6

Solo tiene sentido instalar en el GAC si muchas y muchas aplicaciones web en el mismo servidor compartirán exactamente las mismas bibliotecas. Por ejemplo, en un servidor Sharepoint puede haber cientos de sitios web que necesitan compartir el mismo elemento web, por lo que en este caso tiene sentido implementar el elemento web compilado en el GAC.

Answer 7

primero, si está instalando esto en una máquina cliente, deberá agregar una acción personalizada para instalar la aplicación en el GAC y otra cuando la elimine.

en el caso A definitivamente no es GAC

en el caso B si su biblioteca cambiará constantemente, necesitará agregar cada versión del ensamblado al gac cada vez y se actualizará a ese ensamblaje

en el caso C, la ejecución uno al lado del otro le permite ejecutar diferentes versiones de ensamblaje y no necesita agregar nada para diferenciar las versiones.

Usado solo si realmente necesita