Estou sempre referenciando DLLs no meu código C #, mas elas continuam sendo um mistério que eu gostaria de esclarecer. Esse é um tipo de despejo cerebral de perguntas sobre DLLs.

Entendo que uma DLL é uma biblioteca vinculada dinamicamente, o que significa que outro programa pode acessar essa biblioteca em tempo de execução para obter "funcionalidade". No entanto, considere o seguinte projeto ASP.NET comWeb.dll eBusiness.dll (Web.dll é a funcionalidade front-end e faz referênciaBusiness.dll para tipos e métodos).

Em que pontoWeb.dll vincular dinamicamente aBusiness.dll? Você percebe muito no HDD do Windows se debatendo em tarefas aparentemente pequenas ao usar o Word (etc.) e eu acho que o Word está disparando e vinculando dinamicamente a funcionalidade de outras DLLs?

1a. Além disso, o que carrega e vincula a DLL - o sistema operacional ou alguma estrutura de tempo de execução, como a estrutura .NET?

1b. Qual é o processo de "vinculação"? As verificações de compatibilidade são feitas? Carregando na mesma memória? O que significa realmente vincular?

O que realmente executa o código na DLL? Ele é executado pelo processador ou existe outro estágio de tradução ou compilação antes que o processador entenda o código dentro da DLL?

2a No caso de uma DLL criada em C # .NET, o que está executando isso: a estrutura .NET ou o sistema operacional diretamente?

Uma DLL do Linux funciona em um sistema Windows (se existe algo assim) ou é específica do sistema operacional?

As DLLs são específicas para uma estrutura específica? Uma DLL criada usando C # .NET pode ser usada por uma DLL criada com, por exemplo, Borland C ++?

4a Se a resposta para 4 for "não", qual é o sentido de uma DLL? Por que as várias estruturas não usam seus próprios formatos para arquivos vinculados? Por exemplo: um .exe embutido no .NET sabe que um tipo de arquivo .abc é algo que pode ser vinculado ao seu código.

Voltando aoWeb.dll / Business.dll exemplo - para obter um tipo de classe de cliente, preciso fazer referênciaBusiness.dll deWeb.dll. Isso deve significar queBusiness.dll contém algum tipo de especificação sobre o que realmente é uma classe de cliente. Se eu tivesse compilado meuBusiness.dll arquivar, digamos, Delphi: o C # entenderia e seria capaz de criar uma classe de cliente, ou há algum tipo de informação de cabeçalho ou algo que diz "ei, desculpe, você só pode me usar de outra DLL do Delphi"?

5a O mesmo se aplica aos métodos; posso escrever umCreateInvoice() em uma DLL, compile-o em C ++ e acesse e execute-o em C #? O que para ou me permite fazer isso?

Sobre o seqüestro de DLL, certamente a DLL de substituição (incorreta) deve conter as assinaturas e os tipos exatos do método como aquele que está sendo invadido. Suponho que isso não seria difícil de fazer se você descobrisse quais métodos estavam disponíveis na DLL original.

6a O que no meu programa C # está decidindo se posso acessar outra DLL? Se minha DLL seqüestrada contivesse exatamente os mesmos métodos e tipos que o original, mas fosse compilada em outro idioma, funcionaria?

O que é importação e registro de DLL?