VS Solution, proyectos frente a la mejor práctica de dlls

Question

Cada vez que tengo una biblioteca que utiliza en diferentes sitios web/aplicaciones, siempre acabo de agregar el proyecto de la biblioteca a la misma solución y hacer referencia desde allí. Esto es genial cuando se necesita depurar dentro de la solución, pero en todas las demás situaciones parece inútil y requiere más espacio en el explorador de soluciones.

Otro aspecto positivo o negativo es que si esa biblioteca es actualizada por alguien más en la empresa y luego construyo otra aplicación que utiliza la misma cosa, posiblemente podrían haber roto la compilación. Si por algún motivo no se puede solucionar con la aplicación actual, puede volver al control de origen y retroceder a una versión anterior, pero esto parece demasiado OTT.

Me preguntaba cuáles son las opiniones de otras personas sobre este tema. ¿Qué hace normalmente, hace referencia al dll o agrega el proyecto a su solución?

Answer 1

Mantenemos nuestras Dlls de producción en una ubicación conocida en una unidad de red y la referencia es a través de la ruta UNC de DFS (sin letra de unidad). De esta forma, podemos tener diferentes versiones de la biblioteca en uso al mismo tiempo y las actualizaciones no rompen el código/fuerzan una recompilación hasta que se necesite usar la versión más nueva. Se puede usar un esquema de nomenclatura estándar para garantizar que si un proyecto siempre quiere usar la última versión, puede hacerlo.

Answer 2

Mantenga la biblioteca en una carpeta compartida entre proyectos, y simplemente haga referencia a ella. De esta manera, cuando se actualice, los cambios se mantendrán en todas partes. Para la depuración, creo que si mantiene los archivos .pdb para la biblioteca a mano, entonces debería ser capaz de entrar en los dlls, sin embargo, ¿debería preocuparse por la depuración de una biblioteca?

Answer 3

También podría registrar su dll en el GAC. El GAC maneja todas las referencias, versiones, etc. y es seguro. Después de haber asignado una clave segura que es un requisito previo para los dlls que se encuentran en el GAC, usted tiene una forma segura de acceder a Dll y donde está utilizando un servidor compartido, esto puede ser invaluable. Sus sitios que utilizan este dll tienen un puerto de escala central para el ensamblaje. El GAC tiene una gran cantidad de ventajas con varios artículos en MSDN y sin duda cientos en google dedicados a él.