Ce qui casse une interface .net binaire (dll)

Question

Considérez deux dlls .net. Le premier, " application.dll " contient la logique métier principale et le code d'accès aux données. Le second, " webservice.dll " consiste principalement en WebMethods qui lient des objets et des méthodes avec application.dll dans le but de fournir des appels de service Web au code existant.

Quels changements (ajout de nouvelles classes, ajout d'un nouveau champ ou d'une nouvelle méthode à une classe existante, etc.) peuvent et ne peuvent pas être apportés à application.dll sans nécessiter une recompilation de webservice.dll?

Answer 1

La plupart des choses iront bien; certaines choses qui vont le casser:

• Suppression des * types utilisés (sauf si vous utilisez le transfert de type)
• Supprimer les méthodes * utilisées (y compris le constructeur)
• Modification de la signature des méthodes (utilisées)
• Modification des champs publics en propriétés (utilisées)
• Modification des internes de la sérialisation si la sérialisation est utilisée
• Ajout d'une méthode à une interface, où la deuxième DLL a un type qui implémente cette interface
• Ajout d'une méthode abstraite à une classe de base héritée de la deuxième dll
• Presque tout ce qui est interne si la réflexion de hacky est (ab) utilisée
• Ajout de contraintes à un type / méthode générique
• Marquage d'un type comme scellé lorsqu'il a été hérité dans la deuxième dll
• Ajout d'un champ à une struct si l'appelant utilise l'initialisation par membre plutôt que l'initialisation par constructeur

(la suppression inclut la modification de l'accessibilité en un élément non public)

Answer 2

Techniquement, le nom le divisera (nom, version et jeton de clé dans le cas d'assemblés nommés forts). Sinon, le framework essaiera de charger et d'utiliser la DLL, et cela fonctionnera plus ou moins bien jusqu'à ce qu'il atteigne un type différent ou une signature de méthode différente, un type manquant, etc. L’utilisation de noms revient directement dans les enfers des DLL (ou leurs problèmes).

Je suggère d'en savoir plus sur la la version d'assemblage pour avoir une idée. comment résoudre ces problèmes.

Answer 3

vous pouvez apporter des modifications à application.dll sans exiger la recompilation de webservice.dll tant que vous n'appelez pas les nouvelles classes, fonctions [ajoutées à application.dll]. si vous souhaitez utiliser l'une des modifications de votre application.dll dans webservice.dll, vous devez alors recompiler le service webservice.dll

Bien sûr, si vous modifiez la signature ou le niveau d'accès de l'une des méthodes ou des propriétés de application.dll utilisées par websrvice.dll, votre code sera cassé dans le service Web.