Ubicación de Dll de terceros en el control de versiones para el proyecto .NET

Cuál sería la ubicación (directorio) ideal para comprobar los Dll de referencia de terceros para un proyecto .NET en un sistema de control de versiones. Por lo general, he visto a la mayoría de las personas ponerlos en un contenedor, de modo que el tiempo de ejecución pueda recoger automáticamente estos archivos. Sin embargo, ese es el camino correcto a seguir.Ubicación de Dll de terceros en el control de versiones para el proyecto .NET

Originalmente quería tener un directorio separado que sea paralelo a bin llamado lib que contendrá todos los Dll's de terceros, pero esto necesita cambios en el archivo de configuración de aplicaciones para que el directorio lib sea recogido por el tiempo de ejecución. Mi idea aquí es que lib contendrá dll's de terceros mientras que bin contendrá los proyectos Binary (podría ser Dll o Exe)

¿Cuál es la forma preferida? La concentración es la ubicación en el Control de versiones y no solo el Sistema de archivos físicos.

Fuente

2009-04-18 Dinesh Manne

¿Por qué es esto una preocupación? "Originalmente quería tener un directorio separado que sea paralelo a bin llamado lib, que contendrá todos los Dll de terceros, pero esto necesita cambios en el archivo de configuración de aplicaciones para que el directorio de lib sea recogido por el tiempo de ejecución" –

bien parece que no todo el mundo sabe que puedes hacer un enlace de tiempo de ejecución a los directorios, y dado que mi objetivo final es hacer que el equipo lo use, se siente complejo para ellos. –

se utiliza la siguiente estructura de directorios (más detalles disponibles on my blog):

Solution\ 
    Libraries\ 
    third-party DLLs here 
    Source\ 
    Project1\ 
    Project2\

cada proyecto referencias (utilizando la pestaña "Explorar" en el cuadro de diálogo Agregar referencia) las asambleas en la carpeta "Bibliotecas". Estos se copian automáticamente en la carpeta "bin" de cada proyecto en tiempo de compilación. (La carpeta "Bibliotecas" está, por supuesto, comprometida con el control de versiones.)

Fuente

2009-04-18 15:59:11

Una razón por la que quería tener un directorio lib separado, es que no me gusta la forma en que VS copia sobre dll's al directorio bin, así que quería que la ruta de referencia y la ruta thr runtime del dll sean la misma ruta relativa. Para su información, esta es la forma en que ya tenemos a partir de ahora en el nivel de solución. –

¿Qué ocurre si hay archivos DLL de otros proyectos dentro de la empresa o de código abierto para los cuales genera DLL de terceros desde el código? Ese proyecto publica su DLL. Entonces, ¿ese proyecto compromete su propia DLL cada vez que su código cambia? –

@Munish Goyal: Depende.Si el código cambia con frecuencia y es fácil de desarrollar para todos los desarrolladores del equipo, generalmente asignamos su fuente al control de la versión y la compilamos como parte de la solución. Si el código cambia con poca frecuencia, es difícil o toma mucho tiempo construirlo (por ejemplo, es C++ pero todos los demás proyectos son C#), designamos un desarrollador para que sea el mantenedor de ese proyecto de terceros y para que confirme DLL actualizados siempre que haya un cambio significativo; todos los demás desarrolladores solo hacen referencia a las DLL precompiladas. El flujo de trabajo realmente depende de lo que hace que el proyecto sea fácil de consumir. –

Haga que el directorio independiente contenga los ensamblados de terceros (esto facilitará el mantenimiento en el control de fuente) y luego cree referencias en su proyecto para esos ensamblajes. Luego, en la compilación, sus ensamblajes de terceros se copiarán en su \bin y no tendrá que realizar ningún cambio en la configuración.

Fuente

2009-04-18 11:32:04

Sí, este es el método que casi siempre veo. Un directorio de "Bibliotecas" en el directorio raíz desde el que hace referencia a todas las DLL en su proyecto es el camino a seguir. – Noldorin

Supongo que esas DLL de terceros se usarían en más de un proyecto suyo. Por lo tanto, poner el archivo DLL directamente debajo del contenedor de cada proyecto significa que usted tiene tantas copias de DLL (en el VCS) como proyectos, lo que no es elegante. Como mencionó Andrew H., si los archivos DLL son realmente comunes, deberían incluirse en un directorio común que todos los demás proyectos que lo necesiten lo utilizarán. El único problema aquí es ser capaz de distinguir diferentes versiones de un mismo archivo DLL: con el tiempo, usted puede terminar con algo como:

/common/ThirdPartyLibrary.dll (version 1.2)  
/common/ThirdPartyLibrary.dll (version 1.3)

La mejor manera que conozco (por ahora) en torno a que está cambiando el nombre del tercero DLL de parte con un número de versión explícito y refiérase a ese nuevo nombre en su proyecto, de modo que su proyecto siempre, con seguridad, se referirá a la versión correcta. Me gusta:

/common/ThirdPartyLibrary_v1.2.dll  
/common/ThirdPartyLibrary_v1.3.dll

Fuente

2009-06-26 18:40:50 SClark

Ubicación de Dll de terceros en el control de versiones para el proyecto .NET

Respuesta

Cuestiones relacionadas