Delen via

Hoe codewijzigingen van invloed kunnen zijn op de compatibiliteit

  • Artikel

Compatibiliteits verwijst naar de mogelijkheid om code te compileren of uit te voeren op een versie van een andere .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

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 wijziginggenoemd.

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 brononverenigbare wijziging treedt op wanneer een gebruiker de broncode moet aanpassen om succesvol te bouwen tegen een nieuwere versie van een API.

Compatibiliteit tijdens het ontwerpen

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 in een nieuwere versie van de ontwerpomgeving.

Compatibiliteit met eerdere versies

Compatibiliteit met eerdere versies verwijst naar het vermogen van een bestaande gebruiker van een API om te draaien tegen een nieuwe versie, terwijl het op dezelfde manier blijft functioneren. 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, wordt de API incompatibele achterwaartse.

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

Voorwaartse compatibiliteit

Voorwaartse compatibiliteit verwijst naar de mogelijkheid van een bestaande gebruiker van een API om te werken met een oudere versie terwijl hetzelfde gedrag wordt vertoond. Als een consument niet in staat is om te worden uitgevoerd of zich anders gedraagt wanneer deze wordt uitgevoerd op een oudere versie van de API, wordt de API niet compatibel.

Het onderhouden van forward-compatibiliteit sluit vrijwel alle wijzigingen of toevoegingen van versie tot versie uit, omdat deze wijzigingen voorkomen dat een consument die een latere versie nodig heeft kan werken 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.NET Aspire.