Hoe codewijzigingen van invloed kunnen zijn op de compatibiliteit

Compatibiliteit verwijst naar de mogelijkheid om code te compileren of uit te voeren op een andere versie van een .NET-implementatie dan de versie waarmee de code oorspronkelijk is ontwikkeld. Een bepaalde wijziging kan op zes verschillende manieren van invloed zijn op de compatibiliteit:

• Gedragswijziging
• Binaire compatibiliteit
• Broncompatibiliteit
• Compatibiliteit met ontwerptijd
• Compatibiliteit met eerdere versies
• Doorstuurcompatibiliteit (geen doel van .NET Core)

Gedragswijziging

Een gedragswijziging vertegenwoordigt een wijziging in het gedrag van een lid. De wijziging kan extern zichtbaar zijn (bijvoorbeeld een methode kan een andere uitzondering veroorzaken), of het kan een gewijzigde implementatie vertegenwoordigen (bijvoorbeeld een wijziging in de manier waarop een retourwaarde wordt berekend, de toevoeging of verwijdering van interne methodeaanroepen of zelfs een aanzienlijke prestatieverbetering).

Wanneer gedragswijzigingen extern zichtbaar zijn en het openbare contract van een type wijzigen, zijn ze eenvoudig te evalueren omdat ze van invloed zijn op binaire compatibiliteit. Implementatiewijzigingen zijn veel moeilijker te evalueren; afhankelijk van de aard van de wijziging en de frequentie en patronen van het gebruik van de API, kan de impact van een wijziging variëren van ernstig tot onschuld.

Binaire compatibiliteit

Binaire compatibiliteit verwijst naar de mogelijkheid van een consument van een API om de API te gebruiken op een nieuwere versie zonder hercompilatie. Wijzigingen zoals het toevoegen van methoden of het toevoegen van een nieuwe interface-implementatie aan een type hebben geen invloed op binaire compatibiliteit. Het verwijderen of wijzigen van de openbare handtekeningen van een assembly, zodat consumenten geen toegang meer hebben tot dezelfde interface die door de assembly wordt weergegeven, heeft echter invloed op binaire compatibiliteit. Een wijziging van dit type wordt een binaire incompatibele wijziging aangeduid.

Broncompatibiliteit

Broncompatibiliteit verwijst naar de mogelijkheid van bestaande gebruikers van een API om opnieuw te compileren op basis van een nieuwere versie zonder bronwijzigingen. Een incompatibele bronwijziging treedt op wanneer een consument de broncode moet wijzigen zodat deze kan worden gebouwd op basis van een nieuwere versie van een API.

Compatibiliteit met ontwerptijd

Ontwerptijdcompatibiliteit verwijst naar het behoud van de ontwerptijdervaring in verschillende versies van Visual Studio en andere ontwerpomgevingen. Dit kan betrekking hebben op het gedrag of de gebruikersinterface van ontwerpers, maar het belangrijkste aspect van de ontwerptijdcompatibiliteit betreft projectcompatibiliteit. Een project of oplossing moet kunnen worden geopend en gebruikt voor een nieuwere versie van de ontwerpomgeving.

Compatibiliteit met eerdere versies

Compatibiliteit met eerdere versies verwijst naar de mogelijkheid van een bestaande consument van een API die op dezelfde manier wordt uitgevoerd op een nieuwe versie. Zowel gedragswijzigingen als wijzigingen in binaire compatibiliteit zijn van invloed op achterwaartse compatibiliteit. Als een consument niet kan worden uitgevoerd of zich anders gedraagt wanneer deze wordt uitgevoerd op de nieuwere versie van de API, is de API achterwaarts niet compatibel.

Wijzigingen die van invloed zijn op compatibiliteit met eerdere versies worden afgeraden, omdat ontwikkelaars achterwaartse compatibiliteit verwachten in nieuwere versies van een API.

Compatibiliteit doorsturen

Doorstuurcompatibiliteit verwijst naar de mogelijkheid van een bestaande consument van een API die kan worden uitgevoerd op basis van een oudere versie terwijl hetzelfde gedrag wordt getoond. Als een consument niet kan worden uitgevoerd of zich anders gedraagt wanneer deze wordt uitgevoerd op een oudere versie van de API, is de API niet compatibel.

Het onderhouden van forward-compatibiliteit voorkomt vrijwel alle wijzigingen of toevoegingen van versie tot versie, omdat deze wijzigingen voorkomen dat een consument die zich richt op een latere versie, wordt uitgevoerd onder een eerdere versie. Ontwikkelaars verwachten dat een consument die afhankelijk is van een nieuwere API mogelijk niet correct functioneert ten opzichte van de oudere API.

Het handhaven van forward-compatibiliteit is geen doel van .NET Core.