c# - sirve - ayuda con TFS y archivos DLL a los que se hace referencia
se necesita un ensamblado con nombre seguro (4)
He intentado varios métodos para solucionar este problema y he decidido eliminar los dll necesarios en la carpeta bin y asegurarme de que estén incluidos en el proyecto para el control de código fuente. Escuché a la gente decir que esta podría no ser una buena idea, pero nadie me ha dado un buen razonamiento y me ha funcionado bien.
Mi segunda opción sería crear algo de espacio en una red compartida y organizar los diferentes dll de terceros allí. Puede poner sus archivos en carpetas con números verion para mantener las cosas en orden y todos deben tener acceso a todo lo que necesitan, siempre y cuando todos usen las rutas de red normales como referencia.
Agregar una carpeta separada dentro del proyecto también es factible, pero parece desordenado, ya que terminas con archivos adicionales que no deseas incluir en tu versión.
Estamos usando TFS y VS 2010.
He estado trabajando en un proyecto que usa TFS como control de origen. Tengo bastantes dlls que he descargado (como log4net) y que se mencionan en mi proyecto.
Cuando un nuevo programador se conectó a TFS y sacó mi proyecto del control de la fuente, no pudo construir, ya que dijo que le faltaban todos los dlls a los que se hacía referencia.
¿Qué hice mal aquí? ¿Cómo puedo incluir esas DLL referenciadas en el control de código fuente? ¿Debo agregar todos estos dlls a mi proyecto antes de hacer referencia a ellos? cuando hice referencia a ellos, simplemente busqué en mi sistema de archivos.
¡Gracias!
La mejor práctica para DLL de terceros es crear una carpeta "Biblioteca" en la estructura de archivos sln / proj y copiar todos los archivos DLL necesarios en esta carpeta local como referencia. También querrá asegurarse de que estas DLL estén registradas en el control de código fuente. De esta forma, todos los que trabajan en el proyecto obtienen las mismas versiones exactas de todas las DLL, y las rutas de referencia son exactamente las mismas.
Hacer referencia a libs de terceros en una descarga arbitraria o ubicación de instalación será problemático, ya que requerirá que todos los desarrolladores mantengan la misma estructura de descarga para todas las DLL. Además, si todos los usuarios hacen referencia a las DLL fuera de la estructura del proyecto, es más difícil garantizar que todos estén en la misma versión.
La otra opción sería que todos instalen los archivos DLL en el GAC, pero eso también puede ser un problema, especialmente con la administración e implementación de la versión.
La sugerencia de Andy es buena y la he usado en el pasado. En mi trabajo actual, tenemos una carpeta de "referencia" en un recurso compartido de red para que todos construyamos desde. Sin embargo, aquí tenemos una red muy rápida y todos los desarrolladores están en una sola oficina. Esta solución no funcionará tan bien si tiene muchos desarrolladores remotos o una red lenta.
Creé una carpeta "ThirdPartyDLL" en la carpeta de mi proyecto en la que copié todas las DLL adicionales en ella. Luego entré al explorador de código fuente y agregué esos archivos DLL al servidor de la base del equipo para poder estar seguro de que estoy usando las versiones correctas del DLLS para versiones específicas de mi aplicación (y para que todos estén exactamente en la misma página que yo) )
Vista - otras ventanas - Source coontrol explorer Haga clic derecho en la carpeta del proyecto - agregue elementos a la carpeta
No podrá seleccionar una carpeta específica con archivos DLL, pero en su lugar puede seleccionar los archivos DLL individuales dentro de la carpeta. Luego verá que la carpeta "ThirdPartyDLL" aparece en esa ventana.
Una vez hecho esto, esos dlls están en el control de origen de la base del equipo. Siempre que un desarrollador entre, obtendrá la versión más actual de los archivos DLL.
No olvides eliminar las referencias antiguas en tu aplicación y cambiarlas a tu carpeta thirdpartydll.
Solía copiar los archivos DLL en la carpeta bin, pero el problema que encontré fue cuando los DLL se actualizaron. Inicialmente, cuando mi proyecto era pequeño, no era un gran problema. Ahora que tengo varias DLL y aplicaciones que creé, se volvió muy difícil mantener versiones consistentes de DLL fuera de mi proyecto. Mi mejor ejemplo es el dll de licenciamiento que compré. Cuando se actualizó, todas las aplicaciones y bibliotecas deben estar en la misma versión. Si olvidé uno, tuve problemas extraños o la aplicación simplemente dejó de funcionar. Ahora que tengo todo en una carpeta, realizo el cambio una vez y todo se actualiza.
Espero que esto ayude.