En mi proyecto estoy usando algunas bibliotecas de terceros. Los incluyo usando la carpeta de referencias en Visual Studio.Dónde almacenar archivos DLL externos?
¿Pero dónde debería guardar los archivos DLL? Se hace referencia a ellos desde una ruta en el sistema de archivos, pero sería bueno si puedo incluirlo en el proyecto. ¿Pero cómo?
Esto es lo que hago:
También puede agregar una carpeta de solución y agregarlas allí.
la respuesta anterior fue cuando NuGet era en la infancia. Fwiw, mi enfoque en el que tenemos artículos NuGet:
packages.config archivo si es necesario para bloquear la versión de un paquete en particularDe hecho, uso NuGet para administrar incluso las dependencias internas y tengo un feed privado.
Por lo general, la estructura de mis proyectos se parece a esto (como mínimo):
projectname
- trunk
- src
- lib
- support
- docs
- releases
La carpeta trunk contiene la copia de la fuente que estoy trabajando en este momento. Además, hay un directorio 'lib', que contiene todos los ensamblajes de terceros a los que hace referencia mi proyecto.
(hago referencia a los ensamblajes en esa posición).
La carpeta 'releases' contiene ramas del tronco. Por ejemplo, cuando se lanza v1, se toma una rama del tronco para que tenga una copia del código fuente y todas sus dependencias necesarias para compilar la versión 1 de la aplicación. (Esto es útil para las correcciones de errores. Arregle el error en esa rama, combine la corrección con el tronco, reconstruya esa rama y tenga una v1 fija de su aplicación).
Todas estas cosas entran en control de fuente. (Sí, las asambleas a las que se hace referencia también). Al hacerlo, es muy fácil si otro colega tiene que trabajar en el proyecto también. Acaba de obtener la última versión del control de origen, y él (o ella) tiene todo listo para poder compilar y compilar).
(Tenga en cuenta que esto también es cierto si utiliza algo como CruiseControl para continuous integration).
Debería mirar NuGet. Es una extensión de administración de paquetes para Visual Studio 2010 diseñada exactamente para lo que usted desea.
En la ventana de propiedades de Visual Studio para la referencia a la DLL, hay una propiedad llamada 'copia local' - ponga esto en verdad, y que se copiarán en el directorio bin de su proyecto local
Personalmente , Tengo una carpeta en mi control de origen para archivos DLL de terceros (con una carpeta para cada empresa, organización) y los consulto desde allí.
Estos archivos están entonces disponibles para todos los desarrolladores que descarguen la fuente y puedan actualizarse fácilmente.
Eche un vistazo a Tree Surgeon - Crea un árbol de desarrollo para un proyecto .NET, que puede ser un buen punto de partida y desde allí puede improvisar.
Exactamente lo que estaba buscando, gracias por el enlace – NicoGranelli
Para responder correctamente, debe diferenciar entre medio ambiente y conjunto de trabajo.
Medio Ambiente:
conjunto de trabajo:
Debe decidir en qué categoría encaja su componente.
Tome un vistazo a NuGet (gestor de paquetes para Visual Studio) ...
NuGet es una extensión de Visual Studio que hace que sea fácil de instalar y bibliotecas de código abierto actualización y herramientas en Visual Studio .
A continuación, lea este documento NuGet para obtener el crème de la crème:
Acabo de empezar a usar NuGet y me encanta. –
Esta es la mejor respuesta para cualquier desarrollo reciente (2011 en adelante) – OnesimusUnbound
+1 para el recordatorio para añadirlos al control de código fuente ... Debería ser obvio, pero a menudo se pasa por alto. –
El mismo procedimiento que usamos donde trabajo. Importante agregar al control de fuente para asegurarse de que funcionará para todos los demás desarrolladores también. –
Saludos, he reflexionado sobre esta cuestión durante unos días, pero parece un buen consejo. – deanvmc