que - visual studio c# create dll

¿Qué hay en una DLL y cómo funciona? (3)

Siempre estoy haciendo referencia a los archivos DLL en mi código C #, pero han permanecido como un misterio que me gustaría aclarar. Este es un tipo de brain volcado de preguntas con respecto a las DLL.

Entiendo que una DLL es una biblioteca vinculada dinámicamente, lo que significa que otro programa puede acceder a esta biblioteca en tiempo de ejecución para obtener "funcionalidad". Sin embargo, considere el siguiente proyecto ASP.NET con Web.dll y Business.dll ( Web.dll es la funcionalidad del front-end y hace referencia a Business.dll para tipos y métodos).

¿En qué momento Web.dll se Web.dll dinámicamente a Business.dll ? Se nota mucho en el disco duro de Windows al agotar las tareas aparentemente pequeñas cuando se usa Word (etc.) y reconozco que Word está funcionando y vinculando dinámicamente la funcionalidad de otras DLL.
1a. Además, ¿qué carga y vincula el DLL - el sistema operativo o algún marco de tiempo de ejecución como .NET Framework?
1b. ¿Cuál es el proceso de "vincular"? ¿Se realizan comprobaciones de compatibilidad? Cargando en la misma memoria? ¿Qué significa realmente vincular?
¿Qué realmente ejecuta el código en el DLL? ¿El procesador lo ejecuta o hay otra etapa de traducción o compilación antes de que el procesador comprenda el código dentro de la DLL?
2a. En el caso de una DLL integrada en C # .NET, ¿qué está ejecutando esto: el .NET framework o el sistema operativo directamente?
¿Funciona un DLL de Linux en un sistema Windows (si existe tal cosa) o son específicos del sistema operativo?
¿Las DLL son específicas de un marco particular? ¿Puede una DLL creada usando C # .NET ser utilizada por una DLL construida con, por ejemplo, Borland C ++?
4a. Si la respuesta a 4 es "no", ¿cuál es el sentido de una DLL? ¿Por qué los diversos marcos no usan sus propios formatos para los archivos vinculados? Por ejemplo: un .exe incorporado en .NET sabe que un tipo de archivo de .abc es algo que puede vincular a su código.
Volviendo al ejemplo Web.dll / Business.dll : para obtener un tipo de clase de cliente, necesito hacer referencia a Business.dll desde Web.dll . Esto debe significar que Business.dll contiene algún tipo de especificación de lo que es realmente una clase de cliente. Si hubiera compilado mi archivo Business.dll en, por ejemplo, Delphi: ¿C lo entendería y podría crear una clase de cliente, o hay algún tipo de información de encabezado o algo que diga "oye lo siento, solo puedes usarme de otra persona". DLL de Delphi?
5a. Lo mismo aplica para los métodos; ¿Puedo escribir un método CreateInvoice() en una DLL, compilarlo en C ++ y luego acceder y ejecutarlo desde C #? ¿Qué detiene o me permite hacer esto?
En el tema del secuestro de DLL, seguramente el DLL de reemplazo (defectuoso) debe contener las firmas y los tipos de método exactos como el que está siendo secuestrado. Supongo que esto no sería difícil si pudieras averiguar qué métodos estaban disponibles en la DLL original.
6a. ¿Qué en mi programa C # está decidiendo si puedo acceder a otra DLL? Si mi DLL secuestrada contiene exactamente los mismos métodos y tipos que el original, pero se compiló en otro idioma, ¿funcionaría?

¿Qué es la importación de DLL y el registro de DLL?

1) ¿En qué punto web.dll se vincula dinámicamente a business.dll? Se nota mucho en el disco duro de Windows al agotar las tareas aparentemente pequeñas al usar Word, etc., y reconozco que esta palabra se está apagando y enlazando dinámicamente la funcionalidad de otras DLL.

1) Creo que confundes el enlace con la carga. El enlace es cuando todos los controles y equilibrios se prueban para asegurarse de que lo que se solicita esté disponible. En el momento de la carga, partes de la DLL se cargan en la memoria o se intercambian al archivo de paginación. Esta es la actividad HD que estás viendo.

La vinculación dinámica es diferente de la vinculación estática en que en la vinculación estática, todo el código del objeto se pone en el .exe principal en el tiempo del enlace. Con el enlace dinámico, el código del objeto se coloca en un archivo separado (el dll) y se carga en un momento diferente del .exe.

Los enlaces dinámicos pueden ser implícitos (es decir, la aplicación se vincula con una importación lib) o explícitos (es decir, la aplicación usa LoadLibrary (ex) para cargar el dll).

En el caso implícito, / DELAYLOAD se puede utilizar para posponer la carga del dll hasta que la aplicación realmente lo necesite. De lo contrario, al menos algunas partes de él se cargan (mapeadas en el espacio de direcciones del proceso) como parte de la iniciación del proceso. El dll también puede solicitar que nunca se descargue mientras el proceso está activo.

COM usa LoadLibrary para cargar dlls COM. Tenga en cuenta que, incluso en el caso implícito, el sistema está utilizando algo similar a LoadLibrary para cargar el dll en el inicio del proceso o en el primer uso.

2) ¿Qué es lo que realmente ejecuta el código en la DLL? ¿El procesador lo ejecuta o hay otra etapa de traducción o compilación antes de que el procesador comprenda el código dentro de la DLL?

2) Dlls contienen código de objeto como .exes. El formato del archivo dll es casi idéntico al formato de un archivo exe. He oído que solo hay un bit que es diferente en los encabezados de los dos archivos.

En el caso de un archivo DLL creado a partir de C # .net, el framework .Net lo está ejecutando.

3) ¿Funciona una DLL de, por ejemplo, Linux en un sistema Windows (si existe tal cosa) o son específicos del sistema operativo?

3) Las DLL son específicas de la plataforma.

4) ¿Son específicos para un marco particular? ¿Puede una DLL creada utilizando C # .Net ser utilizada por una DLL construida con Borland C ++ (solo ejemplo)?

4) Los Dlls pueden interoperar con otros marcos si se toman precauciones especiales o si se escribe algún código de pegamento adicional.

Los Dlls son muy útiles cuando una empresa vende productos múltiples que tienen capacidades superpuestas. Por ejemplo, mantengo una dll de E / S de ráster que utilizan más de 30 productos diferentes en la empresa. Si tiene varios productos instalados, una actualización de la DLL puede actualizar todos los productos a nuevos formatos de ráster.

5) Volviendo al ejemplo web.dll / business.dll. Para obtener un tipo de clase de cliente, necesito hacer referencia a business.dll desde web.dll. Esto debe significar que business.dll contiene una especificación de lo que realmente es una clase de cliente. Si hubiera compilado mi archivo business.dll, digamos que Delphi lo entendería y podría crear una clase de clientes, o hay algún tipo de información de encabezado o algo que diga "hey, lo siento, solo puedes usarme de otro delphi dll". .

5) Dependiendo de la plataforma, las capacidades de un dll se presentan de varias maneras, a través de archivos .h, .tlb u otras formas en .net.

6) En el tema del secuestro de DLL, seguramente el DLL de reemplazo (defectuoso) debe contener las firmas de método exacto, tipos como el que está siendo secuestrado. Supongo que esto no sería difícil si pudieras averiguar qué métodos estaban disponibles en la DLL original.

6) dumpbin / exports y dumbin / imports son herramientas interesantes para usar en .exe y .dlls

En primer lugar, debe comprender la diferencia entre dos tipos muy diferentes de DLL. Microsoft decidió ir con las mismas extensiones de archivo (.exe y .dll) con .NET (código administrado) y código nativo, sin embargo, DLL de código administrado y DLL nativos son muy diferentes en el interior.

1) ¿En qué punto web.dll se vincula dinámicamente a business.dll? Se nota mucho en el disco duro de Windows al agotar las tareas aparentemente pequeñas al usar Word, etc., y reconozco que esta palabra se está apagando y enlazando dinámicamente la funcionalidad de otras DLL.

1) En el caso de .NET, las DLL generalmente se cargan a pedido cuando se ejecuta el primer método que intenta acceder a algo desde la DLL. Esta es la razón por la que puede obtener TypeNotFoundExceptions en cualquier parte de su código si no se puede cargar una DLL. Cuando algo como Word repentinamente comienza a acceder al HDD mucho, es probable que se intercambie (obteniendo datos que se han intercambiado en el disco para dejar espacio en la RAM).

1a) Además, ¿qué carga y vincula el archivo DLL: el O / S o algún marco de tiempo de ejecución como el .Net framework?

1a) En el caso de los DLL administrados, el .NET framework es lo que carga, JIT compila (compila el bytecode de .NET en código nativo) y vincula los DLL. En el caso de las DLL nativas, es un componente del sistema operativo que carga y vincula la DLL (no es necesaria la compilación porque las DLL nativas ya contienen código nativo).

1b) ¿Cuál es el proceso de "vinculación"? ¿Se hacen comprobaciones de que hay compatibilidad? Cargando en la misma memoria? ¿Qué significa realmente vincular?

1b) La vinculación se produce cuando las referencias (por ejemplo, llamadas a métodos) en el código de llamada a símbolos (por ejemplo, métodos) en la DLL se reemplazan con las direcciones reales de las cosas en la DLL. Esto es necesario porque las direcciones finales de las cosas en la DLL no se pueden conocer antes de que se haya cargado en la memoria.

2) ¿Qué es lo que realmente ejecuta el código en la DLL? ¿El procesador lo ejecuta o hay otra etapa de traducción o compilación antes de que el procesador comprenda el código dentro de la DLL?

2) En Windows, los archivos .exe y .dll son bastante idénticos. Los archivos nativos .exe y .dll contienen código nativo (lo mismo que el procesador ejecuta), por lo que no es necesario traducir. Los archivos .exe y .dll administrados contienen .NET bytecode que es el primer JIT compilado (traducido al código nativo).

2a) En el caso de una DLL construida desde C # .net, ¿qué está ejecutando esto? ¿El framework .Net o el sistema operativo directamente?

2a) Después de que el código ha sido compilado JIT, se ejecuta de la misma manera que cualquier código.

3) ¿Funciona una DLL de, por ejemplo, Linux en un sistema Windows (si existe tal cosa) o son específicos del sistema operativo?

3) Las DLL administradas pueden funcionar tal como están, siempre que los marcos en ambas plataformas estén actualizados y quien haya escrito la DLL no rompió deliberadamente la compatibilidad mediante el uso de llamadas nativas. Las DLL nativas no funcionarán in situ, ya que los formatos son diferentes (aunque el código de la máquina en el interior es el mismo, si ambos son para la misma plataforma de procesador). Por cierto, en Linux, las "DLL" se conocen como archivos .so (objeto compartido).

4) ¿Son específicos para un marco particular? ¿Puede una DLL creada utilizando C # .Net ser utilizada por una DLL construida con Borland C ++ (solo ejemplo)?

4) Las DLL administradas son particulares del framework .NET, pero naturalmente funcionan con cualquier lenguaje compatible. Las DLL nativas son compatibles siempre que todos utilicen las mismas convenciones (convenciones de llamadas (cómo se pasan los argumentos de función en el nivel de código de máquina), nombres de símbolo, etc.)

5) Volviendo al ejemplo web.dll / business.dll. Para obtener un tipo de clase de cliente, necesito hacer referencia a business.dll desde web.dll. Esto debe significar que business.dll contiene una especificación de lo que realmente es una clase de cliente. Si hubiera compilado mi archivo business.dll, digamos que Delphi lo entendería y podría crear una clase de clientes, o hay algún tipo de información de encabezado o algo que diga "hey, lo siento, solo puedes usarme de otro delphi dll". .

5) Las DLL administradas contienen una descripción completa de cada clase, método, campo, etc. que contienen. AFAIK Delphi no es compatible con .NET, por lo que crearía DLL nativas, que no se pueden usar en .NET directamente. Probablemente podrá llamar funciones con PInvoke, pero las definiciones de clase no se encontrarán. No uso Delphi, así que no sé cómo almacena información de tipo con DLL. C ++, por ejemplo, se basa en archivos de encabezado (.h) que contienen las declaraciones de tipo y deben distribuirse con la DLL.

6) En el tema del secuestro de DLL, seguramente el DLL de reemplazo (defectuoso) debe contener las firmas de método exacto, tipos como el que está siendo secuestrado. Supongo que esto no sería difícil si pudieras averiguar qué métodos estaban disponibles en la DLL original.

6) De hecho, no es difícil de hacer si puede cambiar fácilmente la DLL. La firma de código se puede usar para evitar esto. Para que alguien pueda reemplazar una DLL firmada, deberían saber la clave de firma, que mantuvo en secreto.

6a) ¿Alguna pregunta repetida aquí pero esto se remonta a lo que en mi programa C # está decidiendo si puedo acceder a otra DLL? Si mi DLL secuestrado contenía exactamente los mismos métodos y tipos que el original, pero se compiló en otro idioma, ¿funcionaría?

6a) Funcionaría siempre que sea una DLL administrada, hecha con cualquier lenguaje .NET.

¿Qué es la importación de DLL? y el registro dll?

La "importación de DLL" puede significar muchas cosas, por lo general, significa hacer referencia a un archivo DLL y usar elementos en él.

El registro DLL es algo que se hace en Windows para registrar globalmente archivos DLL como componentes COM para que estén disponibles para cualquier software en el sistema.

Un archivo .dll contiene un código compilado que puede usar en su aplicación.

A veces la herramienta utilizada para compilar el .dll importa, a veces no. Si puede hacer referencia al .dll en su proyecto, no importa qué herramienta se utilizó para codificar las funciones expuestas del .dll.

La vinculación ocurre en el tiempo de ejecución, a diferencia de las bibliotecas vinculadas estáticamente, como las clases, que se vinculan en tiempo de compilación.

Puede pensar en .dll como una caja negra que proporciona algo que su aplicación necesita y que no desea escribir usted mismo. Sí, alguien que entiende la firma .dll podría crear otro archivo .dll con código diferente dentro y su aplicación de llamada no podría saber la diferencia.

HTH