Siempre estoy haciendo referencia a las DLL en mi código C #, pero han permanecido como un misterio que me gustaría aclarar. Este es un tipo de volcado de preguntas sobre 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 conWeb.dll yBusiness.dll (Web.dll es la funcionalidad de front-end y hace referenciaBusiness.dll para tipos y métodos).

En que puntoWeb.dll vincular dinámicamente aBusiness.dll? ¿Notó mucho en Windows HDD que se agita por tareas aparentemente pequeñas cuando usa Word (etc.) y calculo que Word se está apagando y vinculando dinámicamente la funcionalidad de otras DLL?

1a. Además, ¿qué carga y vincula la DLL: el sistema operativo o algún marco de tiempo de ejecución como el marco .NET?

1b. ¿Cuál es el proceso de "vinculación"? ¿Se realizan verificaciones de compatibilidad? ¿Cargando en la misma memoria? ¿Qué significa realmente vincular?

¿Qué ejecuta realmente el código en la DLL? ¿Lo ejecuta el procesador o hay otra etapa de traducción o compilación antes de que el procesador entienda el código dentro de la DLL?

2a. En el caso de una DLL integrada en C # .NET, ¿qué está ejecutando esto: el marco .NET o el sistema operativo directamente?

¿Un archivo DLL de Linux funciona en un sistema Windows (si existe) o son específicos del sistema operativo?

¿Las DLL son específicas de un marco particular? ¿Se puede usar un archivo DLL creado con C # .NET por un archivo DLL creado con, por ejemplo, Borland C ++?

4a. Si la respuesta a 4 es "no", ¿cuál es el punto de una DLL? ¿Por qué los distintos marcos no usan sus propios formatos para los archivos vinculados? Por ejemplo: un .exe integrado en .NET sabe que un tipo de archivo de .abc es algo que puede vincular a su código.

Volviendo a laWeb.dll / Business.dll ejemplo: para obtener un tipo de clase de cliente, necesito hacer referenciaBusiness.dll deWeb.dll. Esto debe significar queBusiness.dll contiene algún tipo de especificación sobre qué es realmente una clase de cliente. Si hubiera compilado miBusiness.dll presentar, 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 desde otra DLL de Delphi"?

5a. Lo mismo aplica para los métodos; puedo escribir unCreateInvoice() método en una DLL, compilarlo en C ++, y luego acceder y ejecutarlo desde C #? ¿Qué me detiene o me impide hacer esto?

Sobre el tema del secuestro de DLL, seguramente el reemplazo (malo) de la DLL debe contener las firmas y tipos de métodos exactos como el que está siendo secuestrado. Supongo que esto no sería difícil de hacer si pudiera averiguar qué métodos estaban disponibles en la DLL original.

6a. ¿Qué está decidiendo en mi programa C # si puedo acceder a otra DLL? Si mi DLL secuestrada contuviera 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?