Megosztás a következőn keresztül:

Kompatibilitástörő változások

  • Cikk

Fontos, hogy a .NET-kódtárak egyensúlyt találjanak a meglévő felhasználók stabilitása és a jövő innovációja között. A kódtár-szerzők a kód újrabontása és újragondolása felé hajlanak, amíg nem tökéletes, de a meglévő felhasználók feltörése negatív hatással van, különösen az alacsony szintű kódtárak esetében.

Projekttípusok és kompatibilitástörő változások

A .NET-közösség által használt kódtárak megváltoztatják a kompatibilitástörő változások hatását a végfelhasználói fejlesztőkre.

  • Az olyan alacsony és középszintű kódtárakat , mint a szerializáló, a HTML-elemző, az adatbázis-objektum-relációs leképező vagy a webes keretrendszer, leginkább a kompatibilitástörő változások befolyásolják.

    Az építőelem-csomagokat a végfelhasználói fejlesztők használják alkalmazások, más kódtárak pedig NuGet-függőségekként. Például egy alkalmazást hoz létre, és egy nyílt forráskódú ügyfelet használ egy webszolgáltatás meghívásához. Az ügyfél által használt függőségek kompatibilitástörő frissítése nem javítható ki. Ez a nyílt forráskódú ügyfél, amelyet módosítani kell, és ön nem szabályozhatja azt. Meg kell keresnie a kódtárak kompatibilis verzióit, vagy be kell küldenie egy javítást az ügyféltárnak, és várnia kell egy új verzióra. A legrosszabb eset az, ha két kódtárat szeretne használni, amelyek a harmadik kódtár kölcsönösen nem kompatibilis verzióitól függenek.

  • A magas szintű kódtárak , például a felhasználói felület vezérlői kevésbé érzékenyek a kompatibilitástörő változásokra.

    A magas szintű kódtárakra közvetlenül hivatkozik egy végfelhasználói alkalmazás. Ha kompatibilitástörő változások történnek, a fejlesztő dönthet úgy, hogy a legújabb verzióra frissít, vagy módosíthatja az alkalmazást, hogy működjön a kompatibilitástörő módosítással.

✔️ Gondolja át, hogyan fogja használni a tárat. Milyen hatással lesznek a kompatibilitástörő változások az azt használó alkalmazásokra és kódtárakra?

✔️ Alacsony szintű .NET-kódtár fejlesztésekor minimálisra csökkenti a kompatibilitástörő változásokat.

✔️ Fontolja meg a kódtárak jelentős átírásának közzétételét új NuGet-csomagként.

A kompatibilitástörő változások típusai

A kompatibilitástörő változások különböző kategóriákba sorolhatók, és nem egyformán hatékonyak.

Forrástörés módosítása

A forrásmegtörő változás nem befolyásolja a program végrehajtását, de fordítási hibákat okoz az alkalmazás következő újrafordításakor. Egy új túlterhelés például kétértelműséget okozhat a korábban egyértelmű metódushívásokban, vagy egy átnevezett paraméter megszakítja az elnevezett paramétereket használó hívókat.

public class Task
{
    // Adding a type called Task could conflict with System.Threading.Tasks.Task at compilation
}

Mivel a forrásmegszakítási változás csak akkor káros, ha a fejlesztők újrafordítják az alkalmazásaikat, ez a legkevésbé zavaró kompatibilitástörő változás. A fejlesztők egyszerűen kijavíthatják saját hibás forráskódjukat.

Viselkedéstörő változás

A viselkedésváltozások a leggyakoribb törésváltozások: a viselkedés szinte bármilyen változása logikai hibát okozhat a fogyasztó számára. A tár módosításai, például a metódusadák, a kivételek vagy a bemeneti vagy kimeneti adatformátumok mind negatív hatással lehetnek a tár felhasználóira. Még egy hibajavítás is kompatibilitástörő változásnak minősülhet, ha a felhasználók a korábban hibás viselkedésre támaszkodtak.

A funkciók hozzáadása és a rossz viselkedés javítása jó dolog, de gond nélkül nagyon megnehezítheti a meglévő felhasználók számára a frissítést. Az egyik módszer, amely segít a fejlesztőknek a viselkedéstörő változások kezelésében, az, ha elrejti őket a beállítások mögé. Gépház lehetővé teszi a fejlesztőknek, hogy frissítsenek a tár legújabb verziójára, ugyanakkor a kompatibilitástörő módosítások mellett döntenek. Ez a stratégia lehetővé teszi a fejlesztők számára, hogy naprakészek maradjanak, miközben a felhasználó kódjuk idővel alkalmazkodni tud.

Például ASP.NET Core MVC olyan kompatibilitási verziót tartalmaz, amely módosítja az engedélyezett és letiltott MvcOptionsfunkciókat.

✔️ FONTOLJA meg, hogy az új funkciókat alapértelmezés szerint kikapcsolja, ha azok hatással vannak a meglévő felhasználókra, és hagyja, hogy a fejlesztők egy beállítással a funkció mellett dönthessenek.

A .NET API-k viselkedéstörő változásaival kapcsolatos további információkért lásd : .NET viselkedésváltozások kompatibilitása.

Bináris kompatibilitástörő változás

Bináris kompatibilitástörő változás történik a tár nyilvános API-jának módosításakor, így a kódtár régebbi verzióira lefordított szerelvények már nem tudják meghívni az API-t. Ha például egy metódus aláírását új paraméter hozzáadásával módosítja, az a kódtár régebbi verziójára lefordított szerelvényeket ad vissza MissingMethodException.

A bináris kompatibilitástörő változás egy teljes szerelvényt is megszakíthat. Ha átnevez egy szerelvényt AssemblyName , azzal megváltoztatja az szerelvény identitását, ahogyan az is, hogy hozzáadja, eltávolítja vagy módosítja az szerelvény erős elnevezési kulcsát. A szerelvény identitásának módosítása megszakítja az azt használó összes lefordított kódot.

❌ NE módosítsa a szerelvény nevét.

❌ NE adja hozzá, távolítsa el vagy módosítsa az erős elnevezési kulcsot.

✔️ VEGYE FIGYELEMBE, hogy az interfészek helyett absztrakt alaposztályokat használ.

Ha bármit hozzáad egy felülethez, az azt megvalósító meglévő típusok sikertelenek lesznek. Az absztrakt alaposztály lehetővé teszi egy alapértelmezett virtuális implementáció hozzáadását.

✔️ FONTOLJA meg az ObsoleteAttribute eltávolítani kívánt típusok és tagok elhelyezését. Az attribútumnak rendelkeznie kell a kód frissítésére vonatkozó utasításokkal, hogy ne használják többé az elavult API-t.

Azok a kódok, amelyek típusokat és metódusokat hívnak meg, ObsoleteAttribute létrehoznak egy buildre vonatkozó figyelmeztetést az attribútumhoz kapott üzenettel. A figyelmeztetések időt biztosítanak az elavult API felületét használó felhasználóknak a migrálásra, így az elavult API eltávolításakor a legtöbben már nem használják.

public class Document
{
    [Obsolete("LoadDocument(string) is obsolete. Use LoadDocument(Uri) instead.")]
    public static Document LoadDocument(string uri)
    {
        return LoadDocument(new Uri(uri));
    }

    public static Document LoadDocument(Uri uri)
    {
        // Load the document
    }
}

✔️ FONTOLJA meg, hogy a ObsoleteAttribute típusokat és módszereket a határozatlan ideig alacsony és középszintű kódtárakban tartsa.

Az API-k eltávolítása bináris kompatibilitástörő változás. Figyelembe véve az elavult típusokat és módszereket, ha azok fenntartása alacsony költséggel jár, és nem ad hozzá sok technikai adósságot a könyvtárhoz. A típusok és módszerek eltávolításának mellőzése segíthet elkerülni a fent említett legrosszabb forgatókönyveket.

A .NET API módosításainak bináris kompatibilitását a .NET nyilvános szerződés kompatibilitását ismertető cikkben talál további információt.

Lásd még

Előző