Dela via

Hur kodändringar kan påverka kompatibiliteten

  • Artikel

Kompatibilitet syftar på möjligheten att kompilera eller köra kod på en annan version av en .NET-implementering än den som koden ursprungligen utvecklades med. En viss ändring kan påverka kompatibiliteten på sex olika sätt:

Beteendeförändring

En beteendeförändring representerar en ändring av beteendet för en medlem. Ändringen kan vara externt synlig (till exempel kan en metod utlösa ett annat undantag), eller så kan den representera en ändrad implementering (till exempel en ändring i hur ett returvärde beräknas, tillägg eller borttagning av interna metodanrop eller till och med en betydande prestandaförbättring).

När beteendeändringar är externt synliga och ändrar en typs offentliga kontrakt är de lätta att utvärdera eftersom de påverkar binär kompatibilitet. Implementeringsändringar är mycket svårare att utvärdera. Beroende på typen av ändring och frekvensen och användningsmönstren för API:et kan effekten av en ändring variera från allvarlig till harmlös.

Binär kompatibilitet

Binär kompatibilitet avser möjligheten för en konsument av ett API att använda API:et på en nyare version utan omkompilering. Ändringar som att lägga till metoder eller lägga till en ny gränssnittsimplementering till en typ påverkar inte binär kompatibilitet. Att ta bort eller ändra en sammansättnings offentliga signaturer så att konsumenterna inte längre kan komma åt samma gränssnitt som exponeras av sammansättningen påverkar dock binär kompatibilitet. En ändring av den här typen kallas för en binär inkompatibel ändring.

Källkompatibilitet

Källkompatibilitet syftar på möjligheten för befintliga användare av ett API att kompilera om mot en nyare version utan några källändringar. En inkompatibel källändring inträffar när en konsument behöver ändra källkoden för att den ska kunna byggas mot en nyare version av ett API.

Design-time-kompatibilitet

Design-time-kompatibilitet syftar på att bevara designtidsupplevelsen i olika versioner av Visual Studio och andra designtidsmiljöer. Även om detta kan omfatta beteendet eller användargränssnittet för designers, gäller den viktigaste aspekten av designtidskompatibilitet projektkompatibilitet. Ett projekt eller en lösning måste kunna öppnas och användas i en nyare version av designmiljön.

Bakåtkompatibilitet

Bakåtkompatibilitet syftar på möjligheten för en befintlig konsument av ett API att köra mot en ny version samtidigt som den beter sig på samma sätt. Både beteendeändringar och ändringar i binär kompatibilitet påverkar bakåtkompatibiliteten. Om en konsument inte kan köra eller beter sig annorlunda när den körs mot den nyare versionen av API:et är API:et bakåtkompatibelt.

Ändringar som påverkar bakåtkompatibiliteten rekommenderas inte eftersom utvecklare förväntar sig bakåtkompatibilitet i nyare versioner av ett API.

Vidarebefordra kompatibilitet

Vidarebefordra kompatibilitet syftar på möjligheten för en befintlig konsument av ett API att köra mot en äldre version samtidigt som samma beteende visas. Om en konsument inte kan köra eller beter sig annorlunda när den körs mot en äldre version av API:et är API:et inkompatibelt.

Att upprätthålla vidarebefordran av kompatibilitet utesluter praktiskt taget alla ändringar eller tillägg från version till version, eftersom dessa ändringar hindrar en konsument som riktar sig mot en senare version från att köras under en tidigare version. Utvecklare förväntar sig att en konsument som förlitar sig på ett nyare API kanske inte fungerar korrekt mot det äldre API:et.

Att upprätthålla kompatibilitet framåt är inte ett mål för .NET Core.