Comment les modifications de code peuvent affecter la compatibilité
de compatibilité fait référence à la possibilité de compiler ou d’exécuter du code sur une version d’une implémentation .NET autre que celle avec laquelle le code a été développé à l’origine. Une modification particulière peut affecter la compatibilité de six façons différentes :
- changement comportemental
- Compatibilité binaire
- Compatibilité de la source
- Compatibilité à l'instant de la conception
- compatibilité descendante
- de compatibilité avec les versions futures (pas un objectif de .NET.NET Aspire)
Changement comportemental
Un changement comportemental représente une modification du comportement d’un membre. La modification peut être visible en externe (par exemple, une méthode peut lever une exception différente) ou représenter une implémentation modifiée (par exemple, une modification de la façon dont une valeur de retour est calculée, l’ajout ou la suppression d’appels de méthode internes, voire une amélioration significative des performances).
Lorsque les modifications comportementales sont visibles en externe et modifient le contrat public d’un type, elles sont faciles à évaluer, car elles affectent la compatibilité binaire. Les changements d’implémentation sont beaucoup plus difficiles à évaluer ; en fonction de la nature du changement et de la fréquence et des modèles d’utilisation de l’API, l’impact d’une modification peut varier de grave à innocu.
Compatibilité binaire
La compatibilité binaire fait référence à la capacité d’un consommateur d’une API à utiliser l’API sur une version plus récente sans recompilation. Les modifications telles que l’ajout de méthodes ou l’ajout d’une nouvelle implémentation d’interface à un type n’affectent pas la compatibilité binaire. Toutefois, la suppression ou la modification des signatures publiques d’un assembly afin que les consommateurs ne puissent plus accéder à la même interface exposée par l’assembly affecte la compatibilité binaire. Un changement de ce type est appelé changement binaire incompatible.
Compatibilité de la source
La compatibilité de la source fait référence à la capacité des consommateurs existants d’une API à recompiler par rapport à une version plus récente sans aucune modification de source. Une modification de source incompatible se produit lorsqu'un consommateur doit modifier le code source pour qu'il soit compilé avec succès sur une nouvelle version d'une API.
Compatibilité au moment du design
La compatibilité au moment du design fait référence à la préservation de l’expérience au moment du design entre les versions de Visual Studio et d’autres environnements au moment du design. Bien que cela puisse impliquer le comportement ou l’interface utilisateur des concepteurs, l’aspect le plus important de la compatibilité au moment du design concerne la compatibilité des projets. Un projet ou une solution doit être ouvert et utilisé sur une version plus récente de l’environnement au moment du design.
Rétrocompatibilité
La compatibilité descendante fait référence à la capacité d’un consommateur existant d’une API à s’exécuter sur une nouvelle version tout en se comportant de la même façon. Les modifications comportementales et les changements de compatibilité binaire affectent la compatibilité descendante. Si un consommateur n'est pas en mesure de fonctionner ou se comporte différemment lors de l'exécution sur la version plus récente de l'API, l'API est non rétrocompatible.
Les modifications qui affectent la compatibilité descendante sont déconseillées, car les développeurs s’attendent à une compatibilité descendante dans les versions plus récentes d’une API.
Compatibilité vers l’avant
La compatibilité ascendante fait référence à la capacité d’un consommateur existant d’une API à s’exécuter sur une version antérieure tout en présentant le même comportement. Si un consommateur n'est pas capable de fonctionner ou se comporte différemment lorsqu'il est exécuté avec une version antérieure de l'API, l'API est avant incompatible.
La gestion de la compatibilité ascendante empêche pratiquement toute modification ou ajout de version à version, car ces modifications empêchent un consommateur qui cible une version ultérieure de s’exécuter sous une version antérieure. Les développeurs s’attendent à ce qu’un consommateur qui s’appuie sur une API plus récente ne fonctionne pas correctement par rapport à l’ANCIENNE API.
Le maintien de la compatibilité ascendante n’est pas un objectif de .NET.NET Aspire.
