none
Cuál es la manera correcta de referenciar una DLL de terceros? RRS feed

  • Pregunta

  • Buenas,

    He visto varias formas en que lo hacen.

    - Pegar la dll en la carpeta bin del proyecto a través del Explorarador de Windows (es decir un copy and paste). Aunque eso solo me ha funcionado en un proyecto WebForms con VB pero ya no un un proyecto Net Core 2.1

    - La otra forma es Agregar Referencia / Examinar... y seleccionar dónde se encuentra el archivo dll. Esto siempre me ha funcionado, tanto en WebForms, MVC 5 y veo que también en NetCore. Sin embargo, cuando veo las propiedad del ensamblado tiene 2 propiedades en particular que me llaman la atención Copia local (que tiene valor vacío) y Ruta de acceso (que tiene como valor la ruta a la cual se hace referencia). La diferencia que observo es que si a Copia local le asigno el valor Si, ya puedo eliminar la dll. de donde hice la referencia, me pregunto dónde ha copiado la dll? debe haberla guardado en algún lugar de la solución para que cada vez que compilo genere la dll en la salida. Me imagino que debe establecerse siempre en Si.

    Por otro lado, dado que por defecto los archivos .dll no se versionan en git y cada vez que alguien quiera clonar el repositorio tendría esta persona que obtener la dll por otro medio y no a través del repositorio y realizar el proceso de referencia.

    Favor si me aclaran estas dudas. Muchas gracias.

    sábado, 10 de agosto de 2019 13:13

Respuestas

  • hola

    >>Cada vez que un desarrollador del equipo clona el proyecto tiene que estar solicitando al alguien que le pase la Dll faltante porque el proyecto no compila

    pero porque no suben las dll al repositorio asi todo que lo descargue tambien obtendra estas liberias?

    No veo cual es el problema, cuando lo que comenta claramente es un fallo del desarrollador que olvido hacer un Add de las librerias que referencio al repositorio git

    Las dll NUNCA van en el \bin esta es una carpeta que no administras y el VS al compilar puede eliminar

    Si son dll que no se referencian por nuget o algun otro manager de libreria de terceros, entonces podrias crearte una carpetra a nivel del .sln y ponerlas alli

    Podria ser una carpeta, no se, de nombre "lib", "ThirPpartyLibraries" o el nombre que mas te guste, entonces colocas alli las dll y las referencias en tus proyectos, pero cuando subas el codigo al repo git tambien debes agregar esta carpeta y las dll para que todo el resto las descarguen 

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta eduar2083 lunes, 12 de agosto de 2019 16:10
    lunes, 12 de agosto de 2019 5:01

Todas las respuestas

  • Hola

    me pregunto dónde ha copiado la dll?

    la guarda en el direcctorio Bin\debug y cuando la empaquetas en Bin\Release

    cuando las clonas de git solo las compilas y cargas la referencia

    sábado, 10 de agosto de 2019 14:33
  • Hola Marti,

    cuando las clonas de git solo las compilas y cargas la referencia

    => Si una persona clona el proyecto y compila le va a tirar error porque en el repositorio no estará la dll dado que las dll no se versionan. Creo que los pasos a seguir serían:

    - Clonar el proyecto

    - Agregar las referencias de terceros

    - Compilar la solución

    No sé si estoy en lo correcto


    • Editado eduar2083 sábado, 10 de agosto de 2019 15:42
    sábado, 10 de agosto de 2019 15:41
  • Revisa tu archivo. gitignore y habilita que se tengan en cuenta esas DLL

    Te pongo ejemplos y documentación de dicho archivo 

    https://git-scm.com/docs/gitignore

    https://gist.github.com/octocat/9257657

    Ahora bien. Esas librerias de terceros se pueden distribuir libremente? 


    Si se solucionó tu consulta no olvides marcar la respuesta. Si te ayudó, vótala como útil. Saludos

    sábado, 10 de agosto de 2019 19:56
    Moderador
  • Hola Sergio,

    Ya me hago lo idea de lo que intentas plantearme.

    Si las librerías son de libre distribución, las subo al repositorio de Git y que se descargue junto con la solución. Caso contrario, que no se suban y se obtengan por otros medios y se agreguen como referencia al proyecto para que pueda compilar y ejecutarse. Creo que por ahí va tu respuesta si no me equivoco

    Pues te comento que estamos desarrollando una aplicación web. Se trata de un proyecto con un repositorio privado. Cada vez que un desarrollador del equipo clona el proyecto tiene que estar solicitando al alguien que le pase la Dll faltante porque el proyecto no compila así una y otra vez pasa muy a menudo. Es una Dll que fue desarrollada por otro equipo de la misma empresa y que la utilizan en varias soluciones.






    • Editado eduar2083 sábado, 10 de agosto de 2019 22:20
    sábado, 10 de agosto de 2019 22:16
  • Usas Azure Devops para almacenar tus repositorios privados? si es así puedes usar Azure Artifacts para almacenar tus paquetes NuGet, npm... Ojo, digo paquetes. Lo mejor que puedes hacer es referenciar paquetes. Con Azure Artifacts puedes crear un feed privado para distribuir tus paquetes. Crearías una especie de nuget.org privado. Tienes posibilidad de que esas DLL sean distribuidas como paquetes Nuget? En varios proyectos de mi empresa usamos paquetes privados de librerías que usamos en muchos proyectos (reutilizar componentes vaya). 

    Si se solucionó tu consulta no olvides marcar la respuesta. Si te ayudó, vótala como útil. Saludos


    sábado, 10 de agosto de 2019 22:33
    Moderador
  • Hola Sergio,

    Utilizamos GitLab sistema de versionamiento. Le echaré una mirada a la creación de paquetes privados que mencionas.

    Muchas gracias.

    domingo, 11 de agosto de 2019 14:58
  • hola

    >>Cada vez que un desarrollador del equipo clona el proyecto tiene que estar solicitando al alguien que le pase la Dll faltante porque el proyecto no compila

    pero porque no suben las dll al repositorio asi todo que lo descargue tambien obtendra estas liberias?

    No veo cual es el problema, cuando lo que comenta claramente es un fallo del desarrollador que olvido hacer un Add de las librerias que referencio al repositorio git

    Las dll NUNCA van en el \bin esta es una carpeta que no administras y el VS al compilar puede eliminar

    Si son dll que no se referencian por nuget o algun otro manager de libreria de terceros, entonces podrias crearte una carpetra a nivel del .sln y ponerlas alli

    Podria ser una carpeta, no se, de nombre "lib", "ThirPpartyLibraries" o el nombre que mas te guste, entonces colocas alli las dll y las referencias en tus proyectos, pero cuando subas el codigo al repo git tambien debes agregar esta carpeta y las dll para que todo el resto las descarguen 

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta eduar2083 lunes, 12 de agosto de 2019 16:10
    lunes, 12 de agosto de 2019 5:01
  • >>Le echaré una mirada a la creación de paquetes privados que mencionas.

    para que complicarte con paquetes si solo es cuestion de subir las dll junto al codigo, no necesitas nada extra para que todos los desarrolladores puedan compilar sin necesidad de pedir las librerias

    los paquetes aplican cuando vas a reusarlo en varios proyectos de forma repetitiva y quieres ademas un sistema de versionado

    si es algo para un solo proyecto puntual no hace falta

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    lunes, 12 de agosto de 2019 5:03
  • Hola Leandro, si te fijas se comenta lo siguiente:"Es una Dll que fue desarrollada por otro equipo de la misma empresa y que la utilizan en varias soluciones". Para mi, un gestor de paquetes es esencial, sobre todo para el versionado de loas mismos. Puede que esa DLL implementada sufra cambios, por lo que generar o paquetes enseguida te das cuenta de que existe nueva versión. 

    Si se solucionó tu consulta no olvides marcar la respuesta. Si te ayudó, vótala como útil. Saludos

    lunes, 12 de agosto de 2019 9:39
    Moderador
  • hola Sergio

    Si entiendo, si es algo que se reusara en varios desarrollos esta claro que lo que recomiendas es lo optimo, crear un paquete es el mejor camino

    Pero bueno, no conozco GitLab si permite crear un servicio similar a nuget privado y por ahi crear un empaquetado publico no sea buena idea, sino se debera tener un servicio como MyGet que permite crear un server nuget local

    Para no tener que enfrentarse a todo eso al menos decia que podia poner las dll en una estructura que permita subirlo junto al desarollo y asi descargar todo junto

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    lunes, 12 de agosto de 2019 13:13
  • Hola,

    Cada día aprendo de lo que ustedes comentan.

    Entonces, si se tratara de una DLL que no va a sufrir cambios, o una DLL que ya nunca va a ser modificada, o es más, que nisiquiera se tiene el código fuente, creo que optaría por el camino que menciona Leandro; y lo que menciona es realmente algo que siempre me pregunté (lo de agregar una carpeta a la solución y adjuntar allí las .dll como parte del proyecto) de esta forma al agregar la referencia utilizará esa DLL adjunta. Esto implica obviamente modificar el archivo .gitignore para que dichos archivos suban al repositorio remoto.

    Por otro lado, creo que optaría por lo que menciona Sergio, si en primer lugar se tiene acceso al código fuente de las DLL y estas cambian continuamente.

    Para mi caso, a pesar de que se tiene la fuente de dicho componente pero esta es gestionada por otro equipo de la empresa, creo que optaré por la opción que indica Leandro.  No tengo experiencia en creación de paquetes así que investigaré al respecto y se lo propondré al otro equipo para que contemple esta alternativa.

    Les agradezco muchísimo!!!

    Saludos.

    lunes, 12 de agosto de 2019 14:59
  • Hola, eso es. Al final hay que analizar lo que tenemos. Efectivamente, la Dll podria incluirse en el proyecto modificando el gitignore como indiqué. Comenté lo de los paquetes ya que me parece la forma más óptima de distribuir componentes. Me gusta la idea de que lo propongas al equipo responsable de ese ensamblado.

    Si se solucionó tu consulta no olvides marcar la respuesta. Si te ayudó, vótala como útil. Saludos

    lunes, 12 de agosto de 2019 15:41
    Moderador