Revisando instalaciones GAC

Esto da vueltas y vueltas, lo sé, pero parece que no puedo encontrar una respuesta satisfactoria.Revisando instalaciones GAC

¿Los ensambles deben ir en el GAC? Estas preguntas: when-and-when-not-to-install-into-the-gac y What are the advantages and disadvantages of using the GAC, abordan exactamente eso, pero las respuestas son en gran medida "se recomienda que ..." o "solo debería ...". ¿¿¿Por qué???

Muchos de los blogs de Naysay del GAC parecen fechar desde hace 5/6 años cuando la estrella de .Net comenzaba su ascenso. ¿Todavía estamos allí ahora? Sin duda, DLL-Hell es una cosa del pasado, ya que el GAC apoya la instalación lado a lado de las diferentes versiones del "mismo" ensamblaje.

Déjame aclarar mis preocupaciones. Tenemos un conjunto creciente de aplicaciones web (5 hasta ahora). Estas son, en esencia, extensiones de una aplicación de terceros a través de llamadas API y extensiones de bases de datos. Obviamente, por lo tanto, todas estas aplicaciones comparten una gran cantidad de código en común y estamos desarrollando un nuevo conjunto de bibliotecas compartidas para mejorar nuestra calidad, mantenibilidad, etc.

Seguramente quiero que esta funcionalidad compartida se instale una vez y se comparta. Todos los argumentos sobre la apertura de una pesadilla de mantenimiento parecen basarse en un mundo de poca disciplina. Si rompe el ABI, entonces golpear el AssemblyVersion es suficiente para mantener sus aplicaciones existentes funcionando.

¿Es el GAC realmente una trampa de miel para los desprevenidos? ¿Estoy siendo ingenuo? ¿Estoy siendo innecesariamente duro cuando rechazo argumentos que citan la pérdida de la instalación de 'XCopy' como silbidos perezosos? ¿O se está poniendo un poco "religioso" y debería ir con lo que parece correcto?

Gracias por ayudarme a ver la luz.

Dan

Fuente

2010-03-04 Dan Kendall

Siguiendo con la respuesta de David, he llegado a la conclusión de que el GAC es un lugar fino y respetable para almacenar nuestros conjuntos siempre que tengamos cuidado con los cambios que hacemos. Creo que una única entidad instalable en un único lugar identificable hará que nuestra estrategia general de desarrollo e implementación sea más fácil de administrar y mantener. Así que, gracias de nuevo a David por su respuesta. Lo he marcado como una respuesta, aunque este es claramente un área de cierta subjetividad. Dan –

Personalmente, nunca he instalado ningún ensamblaje directamente en el GAC (excepto como un ejercicio puramente académico). He escuchado la discusión antes sobre el uso de un ensamblaje desde una ubicación centralizada a la que se accede desde varias aplicaciones, y aunque eso parece algo atractivo, personalmente, no vale la pena el tiempo. Las computadoras vienen con 320GB de espacio en el disco duro estos días ... mi miserable ensamblaje de 160K no va a hacer mella en eso, incluso si se copia 5 veces. (Por supuesto, algunos podrían argumentar el "problema de los comunes" ... ya sabes: "si cada desarrollador pensara de esa manera ...", pero estoy divagando). La razón principal por la que decido no hacer esto es porque una aplicación en particular puede confiar en el ensamblaje de una manera, mientras que otra puede confiar en ella de otra manera. Si bien en un mundo ideal, las actualizaciones de este ensamblaje nunca deberían afectar las aplicaciones que dependen de él, en realidad, a menudo lo hace. Si estoy solucionando un problema con un ensamblaje porque una aplicación en particular tiene problemas, estoy afectando inconscientemente las otras aplicaciones que dependen de ese ensamblaje en particular. Por otro lado, algunos podrían argumentar que este tipo de situación nos hace mejores programadores y hace que nuestro ensamblaje GAC-Shared sea más a prueba de balas. Eso es genial, pero mi trabajo como programador no es principalmente para convertirme en un mejor programador, sino para escribir programas que funcionen, y al hacerlo, me convertiré en un mejor programador.

Entonces, ¿cuál es mi voto? Mantener alejado del GAC. Deje que cada aplicación confíe en la versión del ensamblaje en el que están construidos para confiar.Un error expuesto en ese ensamblado por una aplicación puede no aparecer nunca en las otras aplicaciones, porque están usando el ensamblaje de manera diferente, déjelos así y no tendrá que realizar regresiones para probar 5 aplicaciones diferentes cada vez que su DLL compartida se aplique. .

Fuente

2010-03-04 11:29:12

Sí, el espacio en disco no es realmente mi preocupación :) Agradezco la honestidad de su respuesta, pero tengo que argumentar que si dos consumidores de código compartido exhiben un comportamiento diferente pero correcto, entonces hay un interrogante sobre la separación de la funcionalidad. Creo que veo las cosas al revés: si me convierto en un mejor programador, entonces, QED, escribo mejores programas. –

Yo diría que definitivamente hay un equilibrio, sin embargo. Sí, desea convertirse en un mejor programador, y convertirse en un mejor programador le ayuda a escribir mejores programas, pero hay mejores formas de convertirse en un mejor programador que en los ensambles de producción de cocción a presión. –

No estoy seguro de entender su término "cocinar a presión". Estoy totalmente de acuerdo con la necesidad de un enfoque equilibrado y pragmático. El problema es que parece que se pueden parafrasear las respuestas de usted y de los demás a la pregunta del GAC (y simplemente hago esto para aclarar mi preocupación, no para menospreciar su opinión) ya que "creemos que el GAC es una buena idea pero queremos evitarlo". la sobrecarga de hacer que nuestro código funcione felizmente con eso ". Que es una visión más bien ictérica del desarrollo que se presenta en tales respuestas globales. Prefiero conocer los riesgos específicos y tomar una decisión. Por favor corrígeme si estoy equivocado. –

yo uso siguiente estrategia débil.
Use GAC - cuando los diferentes programas usan ensamblado compartido + control de versiones.
No utilice GAC - siempre.

cualquier comentario es bienvenido.

Fuente

2010-03-04 11:28:45

Respuesta

Cuestiones relacionadas