none
Ubicacion de una DLL RRS feed

  • Pregunta

  • Hola Colegas, Bendiciones.

    Talvez les suene algo ridícula u obvia la respuesta a el encabezado de esta pregunta pero me surgió después de leer algunos post y artículos sobre dll en .NET.

    Bueno les cuento, años atrás cuando trabajaba en vb6 desarrolle algunas dll y en una de ellas yo llamaba a otra dll de las que desarrolle y otras del sistema, y un requisito de ellas para poderlas usar sin problema era que su ubicación debía de estar en la carpeta de la app o en su defecto en la carpeta del sistema o sea en c:\windows\system32.

    En .NET cuando uno desarrolla una dll(Biblioteca de clase) la referencia desde su ubicación... cierto

    Ahora las Preguntas:

    Cuando hago la referencia de esta dll desde una ubicación determinada al publicarla por decirlo así como app independiente, debe mantener la misma ubicación?

    o

    Se sigue aplicando las mismas reglas que por decirlo así tenias que usar en vb6, para la ubicación de la dll?

    Espero sus orientaciones al respecto.

    Saludos 

    miércoles, 27 de septiembre de 2017 19:14

Respuestas

  • No, cuando referencias una DLL en tiempo de desarrollo, la ubicación de esa DLL solo se usa para resolver los nombres de clases y sus miembros mientras se compila. La ubicación NO se salva en el ejecutable compilado.

    Por lo tanto, en tiempo de ejecución, es necesario que la DLL se encuentre en una ubicación donde el ejecutable sea capaz de encontrarla. Para ello, el ejecutable sigue un proceso que se denomina Fusion, y que hace que busque en una serie de ubicaciones predeterminadas y otras configurables desde mediante .config (o resolubles dinámicamente desde programación).

    Las ubicaciones más importantes en las que busca el proceso de Fusion son el GAC (ahi están las DLLs de .NET, pero se pueden añadir las tuyas si cumplen los requisitos necesarios), y la misma carpeta del ejecutable. De manera predeterminada, cuando añades una referencia a una DLL, lo que hace Visual Studio al compilar es copiarla al directorio del ejecutable, y por eso el ejecutable la encuentra al ejecutarlo desde Visual Studio. Pero esta copia puede desactivarse desde las Propiedades de la Referencia en caso de que quieras usar otro mecanismo distinto para encontrar la DLL.

    Nótese que el proceso de Fusion NO busca en el System32, por lo que este directorio ya no sirve para ubicar las DLLs en la misma manera en la que se hacía con VB6.

    Y añado otra cosa más: todo lo anterior se aplica a las librerías de código gestionado (es decir, programadas en .NET). Las librerías COM y las DLLs con puntos de entrada convencionales (las que llamas por P/Invoke) no siguen esas reglas.

    miércoles, 27 de septiembre de 2017 20:46
  • Que requisitos debe tener la dll para ser incluida en el "GAC"?

    Tienen que tener un "Strong Name" (en español lo traducen como "nombre seguro"). Esto se hace asignándoles una firma mediante un fichero de claves ".snk" desde las propiedades del proyecto. Si tienes una versión moderna de Visual Studio, el .snk se puede generar directamente desde la propia pestaña de propiedades, sino hay que hacerlo por línea de comandos.
    Las dll son incluidas en el "GAC" si cumplen los requisitos a los que haces referencia de forma automática al instalar la app o no?
    No, no es automático. Si haces el instalador mediante la opción de "proyecto de instalación" (que solo viene de fábrica hasta el Visual Studio 2010, si tienes uno más moderno hay que descargarlo e instalarlo), entonces tienes que añadir las DLLs deseadas a la pseudo-carpeta GAC desde la pestaña de edición del sistema de archivos.
    jueves, 28 de septiembre de 2017 8:13
  • Exacto, ese "lugar común" que mencionas para las librerías que han de ser usadas por varias aplicaciones es precisamente el GAC. Y una de las misiones del instalador es precisamente la de instalar en el GAC las librerías que al crear el proyecto de instalación hayas señalado que deben ir al GAC.
    jueves, 28 de septiembre de 2017 20:13

Todas las respuestas

  • No, cuando referencias una DLL en tiempo de desarrollo, la ubicación de esa DLL solo se usa para resolver los nombres de clases y sus miembros mientras se compila. La ubicación NO se salva en el ejecutable compilado.

    Por lo tanto, en tiempo de ejecución, es necesario que la DLL se encuentre en una ubicación donde el ejecutable sea capaz de encontrarla. Para ello, el ejecutable sigue un proceso que se denomina Fusion, y que hace que busque en una serie de ubicaciones predeterminadas y otras configurables desde mediante .config (o resolubles dinámicamente desde programación).

    Las ubicaciones más importantes en las que busca el proceso de Fusion son el GAC (ahi están las DLLs de .NET, pero se pueden añadir las tuyas si cumplen los requisitos necesarios), y la misma carpeta del ejecutable. De manera predeterminada, cuando añades una referencia a una DLL, lo que hace Visual Studio al compilar es copiarla al directorio del ejecutable, y por eso el ejecutable la encuentra al ejecutarlo desde Visual Studio. Pero esta copia puede desactivarse desde las Propiedades de la Referencia en caso de que quieras usar otro mecanismo distinto para encontrar la DLL.

    Nótese que el proceso de Fusion NO busca en el System32, por lo que este directorio ya no sirve para ubicar las DLLs en la misma manera en la que se hacía con VB6.

    Y añado otra cosa más: todo lo anterior se aplica a las librerías de código gestionado (es decir, programadas en .NET). Las librerías COM y las DLLs con puntos de entrada convencionales (las que llamas por P/Invoke) no siguen esas reglas.

    miércoles, 27 de septiembre de 2017 20:46
  • Alberto,

    Primero Gracias por contestar con esa aclaración.

    Entiendo lo que me dices, que ya no es como se hacia en vb6, que si uno generaba un instalador y la dll que uno desarrollaba la ponía en system32 el empaquetador la tomaba desde ahí y cuando la instalaba la copiaba en ese mismo lugar y al ejecutar la app esta buscaba en la carpeta de la app y después en system32.

    Tu mencionabas sobre el "GAC" estuve leyendo sobre eso antes de escribir esta consulta, y exponías sobre requisitos que debían cumplir la dll, lo cual me lleva a las siguientes preguntas:

    Que requisitos debe tener la dll para ser incluida en el "GAC"?

    y

    Las dll son incluidas en el "GAC" si cumplen los requisitos a los que haces referencia de forma automática al instalar la app o no?

    Expongo estas preguntas por que me gustaría que el usuario al abrir el directorio de la app ciertas dll no las vieras allí.

    Es muy tonto lo que digo...

    bueno y eso gracias de antemano

    miércoles, 27 de septiembre de 2017 22:12
  • Que requisitos debe tener la dll para ser incluida en el "GAC"?

    Tienen que tener un "Strong Name" (en español lo traducen como "nombre seguro"). Esto se hace asignándoles una firma mediante un fichero de claves ".snk" desde las propiedades del proyecto. Si tienes una versión moderna de Visual Studio, el .snk se puede generar directamente desde la propia pestaña de propiedades, sino hay que hacerlo por línea de comandos.
    Las dll son incluidas en el "GAC" si cumplen los requisitos a los que haces referencia de forma automática al instalar la app o no?
    No, no es automático. Si haces el instalador mediante la opción de "proyecto de instalación" (que solo viene de fábrica hasta el Visual Studio 2010, si tienes uno más moderno hay que descargarlo e instalarlo), entonces tienes que añadir las DLLs deseadas a la pseudo-carpeta GAC desde la pestaña de edición del sistema de archivos.
    jueves, 28 de septiembre de 2017 8:13
  • Alberto.

    Gracias por tu respuesta aclarándome lo del "gac" y por la paciencia al describir tus respuestas.

    Entonces que función cumple el instalador ahora?.... solo copia los archivos y nada mas... aa y te crea los accesos directos en el escritorio y en el menú de incio....

    Digo esto... por que imagínate que desarrollas varias app para distintas cosas y un cliente las compra y las instala en el mismo equipo y tu desarrollaste varias dll que estas app usan de forma común entonces cada carpeta va a tener las mismas dll, siendo mas lógico que estén ubicadas en un solo lugar y que si hay otras app que las usan no se dupliquen, no crees... 

    bueno, en fin, que triste estoy. 

    jueves, 28 de septiembre de 2017 19:08
  • Exacto, ese "lugar común" que mencionas para las librerías que han de ser usadas por varias aplicaciones es precisamente el GAC. Y una de las misiones del instalador es precisamente la de instalar en el GAC las librerías que al crear el proyecto de instalación hayas señalado que deben ir al GAC.
    jueves, 28 de septiembre de 2017 20:13