¿A GAC, o no a GAC?

Question

Tengo una capa de acceso a datos (DAL) que está escrita en ASP.NET 3.5 y usa las bibliotecas de prácticas de patrones & de Microsoft (en lo sucesivo, P & P) para lograr su acceso a los datos. Instalé P & P y reside en mi GAC, así que, lógicamente, mi DAL lo hace referencia en el GAC. Por lo tanto, las bibliotecas P & P nunca se despliegan en la carpeta bin de mi DAL.

Uso este proyecto DAL en al menos cinco (más que eso, pero soy demasiado perezoso para tratar de contarlos todos) de diferentes sitios web. Y todo esto funcionó bien para mí porque soy el único desarrollador que trabaja en estos sitios web.

Pero, ahora tengo otros desarrolladores que van a trabajar en algunos de estos sitios web.

El problema: si un desarrollador tira del proyecto DAL abajo desde nuestro repositorio de código, que no va a construir para ellos si no tienen las bibliotecas & P P instalados.

Mi pregunta: debo esperar los desarrolladores instalar las bibliotecas P & P, o debería simplemente deshacerse de ellos en la carpeta bin y hacerse con él?

Me doy cuenta de que tirarlos a la carpeta bin es probablemente la forma más fácil de resolver el problema, pero nunca he sido un gran admirador de la carpeta bin si puedo hacer referencia a ellos en el GAC.

Answer 1

Esta es la preferencia en gran medida estilística para su grupo de trabajo en particular. Tiendo a favorecer los sitios web de empaquetado de la misma manera que paquete las aplicaciones cliente: con todos los archivos binarios requeridos que no sean .NET-framework en la carpeta bin, trabajando con la suposición de que cualquier máquina en la que se copien/instalen no tendrá nada en el GAC. Mi equipo en el trabajo mantiene nuestros ensamblajes de terceros controlados en el código fuente como archivos binarios y etiquetados como dependencias de referencia para que todos trabajen en la misma página con los mismos binarios y nunca tengamos que preocuparnos por las diferencias de instalación entre las máquinas de los desarrolladores.

El GAC puede ser un mecanismo conveniente que ahorra espacio, pero prefiero la consistencia entre los entornos de desarrollador que se proporciona "alineando" los archivos.

Answer 2

Después de haber trabajado en proyectos con dependencias GAC en el pasado, siempre ha sido confuso y difícil configurar proyectos correctamente, causando todo tipo de retrasos apenas comenzando. Puede convertirse en un problema mayor a medida que desarrolla nuevas versiones de DAL. Esto puede haber funcionado bien cuando estuviste solo, pero realmente consideraría el vertedero ahora que tienes un equipo más grande.

Answer 3

Creo que debería darles la opción de hacer ambas cosas.

Para los perezosos, proporcionen los archivos DLL pp, así como una DLL DAL firmada. Para que los más experimentados les permitan compilarlo, solo asegúrense de que saben que necesitan P & P y cualquier cambio en la DLL tendrá que establecerse.

Siempre estoy a favor de las bibliotecas compartidas para ser gac'ed especialmente en el lado del servidor. Para los clientes generalmente me gusta empacar en bin.