O que quebra uma interface binária (dll) .net

Question

Considere duas DLLs .net.O primeiro, "application.dll" contém a lógica de negócios principal e o código de acesso a dados.O segundo, "webservice.dll" consiste principalmente em WebMethods que se vinculam a objetos e métodos com application.dll com a finalidade de fornecer chamadas de serviço da web para o código existente.

O que muda (por ex.adicionar novas classes, adicionar um novo campo ou método a uma classe existente, etc.) pode e não pode ser feito em application.dll sem exigir uma recompilação de webservice.dll?

Answer 1

A maioria das coisas ficará bem;algumas coisas que vão quebrá-lo:

• Removendo* tipos usados ​​(a menos que você esteja usando encaminhamento de tipo)
• Removendo* métodos usados ​​(incluindo construtor)
• Alterando a assinatura dos métodos (que são usados)
• Alterando campos públicos para propriedades (que são usadas)
• Alterando os internos da serialização se a serialização for usada
• Adicionando um método a uma interface, onde a segunda dll possui um tipo que implementa essa interface
• Adicionando um método abstrato a uma classe base herdada na segunda DLL
• Quase tudo interno se a reflexão hacky for (ab)usada
• Adicionando restrições a um tipo/método genérico
• Marcando um tipo como sealed quando foi herdado na segunda dll
• Adicionando um campo a um struct se o chamador usar inicialização de membro em vez de inicialização de construtor

(a remoção inclui a alteração da acessibilidade para algo não público)

Answer 2

Tecnicamente, o nome irá quebrá -lo (nome e versão e token -chave no caso de assembiles nomeados fortes). Caso contrário, a estrutura irá tentar Para carregar e usar a DLL, e isso funcionará mais ou menos bem até atingir uma assinatura diferente do tipo ou método, um tipo ausente etc., mas esteja ciente de que a reutilização de nomes está voltando direto para o inferno da DLL (ou os problemas do mesmo).

Eu sugiro ler mais sobre Versão de montagem Para ter uma idéia de como resolver esses problemas.

Answer 3

Você pode fazer alterações no Application.dll sem a necessidade de recompilar o WebService.dll, desde que não esteja chamando as novas classes, funções [adicionadas no application.dll]. Se você deseja consumir alguma de seu aplicativo.dll alterações no web Service.dll, você precisa recompilar o WebService.dll

É claro que, se você alterar a assinatura ou o nível de acesso de qualquer um dos métodos ou propriedades no Application.dll usado pelo websrvice.dll, ele quebrará seu código no WebService.