C # rupture d'interface, ABI

Question

Supposons que nous ayons la class X dans la version 1 du A.dll de montage:

class X {
    SomeType Property { set; get; }
}

et ensuite dans la version 2 de l'ensemble A.dll:

class X {
    SomeType Property { set; get; }
    SomeType OtherProperty { set; get; }
}

Supposons maintenant que nous avons un deuxième ensemble B.dll que les charges et les utilisations A.dll X. Est-ce que l'ajout de la propriété OtherProperty briser l'ABI? Est-ce que B.dll ne pas utiliser A.dll / X? Dans la négative, l'ordre des déclarations faire une différence? Si les propriétés avaient été virtuel, il avait fait une différence?

Je suppose que je suis vraiment demandé: quelles sont les règles générales ABI? Je sais changeais interfaces après leur publication est une mauvaise chose, mais je voudrais vraiment pouvoir ajouter propriétés dans certains cas, sans ajouter des sous-classes.

Answer 1

Ajout de propriétés devrait être bien.

Un cas qui brisera est si par exemple vous ajouter quelque chose au milieu d'un ENUM automatiquement numéroté. Par exemple, si vous avez ce code dans votre bibliothèque:

enum Foo
{
   Bar,
   Qux
}

et que vous modifiez à ceci:

enum Foo
{
   Bar,
   Baz,
   Qux
}

Ensuite, vous aurez également besoin de recompiler tout code comme ceci:

if (foo == Foo.Qux)
{
    //  ...
}

Answer 2

Le compilateur JIT spackle beaucoup de ce cours, aussi la source du message d'erreur si le changement se brisait.

Vous jouez cependant un jeu très dangereux appelé l'enfer des DLL. Le problème n'est pas qu'ils ne recompiler pas leur code, il est quand ils font . Ils seront, par la suite. Si donc il y a une erreur subtile, quelqu'un a couru une ancienne version de votre installateur, copié le mauvais fichier, etcetera alors tous l'enfer se déchaîne. Le code ne fonctionnera pas et ils vont avoir un impossible emploi comprendre pourquoi. Cela se produit longtemps après que vous avez fait le changement, vous n'aurez pas moyen de deviner ce qui n'a pas non plus et ne peut pas les aider.

Ne pas déranger avec cela, buter [AssemblyFileVersion] et [AssemblyVersion]. Oui, ils doivent recompiler lorsque vous changez le second. Ou l'utilisation <bindingRedirect>, ce qui est bien aussi, maintenant il y a un enregistrement identifiable de celui-ci.

BTW: cela est arrivé dans le .NET Framework aussi. WaitHandle.WaitOne (int) se est ajouté dans un service pack mais sans changement [AssemblyVersion]. Les programmeurs .NET 2.0 ciblées, mais leur code ne fonctionneraient pas lorsque la machine cible avait le 2.0 d'origine installé. très douloureux.

Answer 3

Il ne se cassera pas la compatibilité si est simplement utilisée par le B de montage. Mais il se brisera si le B d'assemblage définit une classe qui implémente l'interface, car cette classe ne met pas en œuvre la propriété nouvellement introduite.