tips software prácticas proyectos proyecto practicas pmi mejores malas las gestion desarrollo control cierre calidad buenas administración .net visual-studio

.net - software - practicas de gestion



Solución VS, mejores prácticas de proyectos vs dlls (3)

Cada vez que tengo una biblioteca que se usa 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 otra persona de la empresa actualiza esa biblioteca y luego construyo otra aplicación que use 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?


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 DFS UNC (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.


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 poder ingresar a los dlls, sin embargo, ¿debería preocuparse por la depuración de una biblioteca?


También puede 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.