Verzió- és frissítési szempontok C#-fejlesztőknek

A kompatibilitás fontos cél, mivel új funkciókat adnak hozzá a C# nyelvhez. A meglévő kód szinte minden esetben probléma nélkül újrafordolható egy új fordítóverzióval. A .NET-futtatókörnyezeti csapat célja a frissített kódtárak kompatibilitásának biztosítása is. Szinte minden esetben, amikor az alkalmazást frissített kódtárakkal rendelkező frissített futtatókörnyezetből indítják el, a viselkedés pontosan ugyanaz, mint a korábbi verziók esetében.

Az alkalmazás fordításához használt nyelvi verzió általában megegyezik a projektben hivatkozott futtatókörnyezeti cél-keretrendszer monikerével (TFM). Az alapértelmezett nyelvi verzió módosításáról további információt a nyelvi verzió konfigurálásával foglalkozó cikkben talál. Ez az alapértelmezett viselkedés biztosítja a maximális kompatibilitást.

A kompatibilitástörő változások bevezetésekor a rendszer a következő besorolást alakítja ki:

• Bináris kompatibilitástörő változás: A bináris kompatibilitástörő változások eltérő viselkedést okoznak, például összeomlást okoznak az alkalmazásban vagy a tárban, amikor új futtatókörnyezetet használnak. A módosítások beépítéséhez újra kell lefordítania az alkalmazást. A meglévő bináris függvény nem fog megfelelően működni.
• Forrástörési változás: A forrástörés módosítása megváltoztatja a forráskód jelentését. Mielőtt összeállítja az alkalmazást a legújabb nyelvi verzióval, szerkesztenie kell a forráskódokat. A meglévő bináris megfelelően fog futni az újabb gazdagéppel és futtatókörnyezettel. Vegye figyelembe, hogy a nyelvszintaxis esetében a forrástörés módosítása viselkedésbeli változás is, a futásidejű kompatibilitástörő változásokban meghatározottak szerint.

Ha egy bináris kompatibilitástörő változás hatással van az alkalmazásra, újra kell lefordítania az alkalmazást, de nem kell szerkesztenie a forráskódot. Ha egy forrástörési változás hatással van az alkalmazásra, a meglévő bináris továbbra is megfelelően fut a frissített futtatókörnyezettel és kódtárakkal rendelkező környezetekben. A forrásmódosításokat azonban az új nyelvi verzióval és futtatókörnyezettel való újrafordításhoz kell elvégeznie. Ha a módosítás forrástörést és bináris kompatibilitástörőt is jelent, újra kell komplikálta az alkalmazást a legújabb verzióval, és frissítenie kell a forrást.

Mivel a C#-nyelvi csapat és a futtatókörnyezeti csapat nem szeretne kompatibilitástörő módosításokat végrehajtani, az alkalmazás frissítése általában a TFM frissítésével és az alkalmazás újraépítésével kapcsolatos. A nyilvánosan elosztott kódtárak esetében azonban gondosan értékelje ki a házirendet a támogatott TFM-ekhez és a támogatott nyelvi verziókhoz. Előfordulhat, hogy új kódtárat hoz létre a legújabb verzióban található funkciókkal, és gondoskodnia kell arról, hogy a fordító korábbi verzióival készült alkalmazások használhassák azt. Vagy frissíthet egy meglévő tárat, és előfordulhat, hogy sok felhasználó még nem frissített verziót.

A kódtárak kompatibilitástörő változásainak bemutatása

Amikor új nyelvi funkciókat vezet be a tár nyilvános API-jában, érdemes kiértékelnie, hogy a funkció bevezetése bináris vagy forrástörő változást vezet-e be a tár felhasználói számára. A belső implementáció azon módosításai, amelyek nem jelennek meg a felületeken vagy protected felületekenpublic, kompatibilisek.

Feljegyzés

Ha engedélyezi a System.Runtime.CompilerServices.InternalsVisibleToAttribute típusok megtekintését a belső tagok számára, a belső tagok kompatibilitástörő változásokat vezethetnek be.

A bináris kompatibilitástörő változásokhoz a felhasználóknak újra kell lefordítaniuk a kódot az új verzió használatához. Vegyük például ezt a nyilvános módszert:

public double CalculateSquare(double value) => value * value;

Ha hozzáadja a in módosítót a metódushoz, az egy bináris kompatibilitástörő változás:

public double CalculateSquare(in double value) => value * value;

A felhasználóknak újra kell lefordítaniük azokat az alkalmazásokat, amelyek az CalculateSquare új kódtár metódusát használják a megfelelő működéshez.

A forrástörő módosításokhoz a felhasználóknak módosítaniuk kell a kódjukat, mielőtt újrafordítanak. Vegyük például ezt a típust:

public class Person
{
    public string FirstName { get; }
    public string LastName { get; }

    public Person(string firstName, string lastName) => (FirstName, LastName) = (firstName, lastName);

    // other details omitted
}

Egy újabb verzióban érdemes kihasználni a típusokhoz record létrehozott szintetizált tagokat. A következő módosítást hajtja végre:

public record class Person(string FirstName, string LastName);

Az előző módosításhoz minden, a forrásból Personszármaztatott típus módosítása szükséges. Minden ilyen deklarációnak hozzá kell adnia a módosítót a record deklarációkhoz.

A kompatibilitástörő változások hatása

Amikor bináris kompatibilitástörő módosítást ad hozzá a kódtárhoz, a kódtárat használó összes projektet újrafordításra kényszeríti. A projektek forráskódjának azonban nem kell megváltoznia. Ennek eredményeképpen a kompatibilitástörő változás hatása meglehetősen kicsi minden projekt esetében.

Ha módosítja a forráskódtárat, minden projektnek módosítania kell a forrást az új kódtár használatához. Ha a szükséges módosításhoz új nyelvi funkciókra van szükség, kényszerítheti a projekteket arra, hogy a jelenleg használt nyelvi verzióra és TFM-re frissítsenek. Több munkát igényelt a felhasználók számára, és valószínűleg a frissítésre is kényszerítette őket.

Az esetleges kompatibilitástörő változások hatása a tártól függő projektek számától függ. Ha a tárat néhány alkalmazás belsőleg használja, reagálhat az összes érintett projekt kompatibilitástörő változásaira. Ha azonban a tárat nyilvánosan letölti, érdemes felmérnie a lehetséges hatásokat, és érdemes megfontolnia az alternatívákat:

• Új API-kat vehet fel, amelyek párhuzamosak a meglévő API-kkal.
• Megfontolhatja a különböző TFM-ekhez tartozó párhuzamos buildeket.
• Megfontolhatja a többhelyes célzást.