Az SDK és a .NET 8 eszközkészletének újdonságai

Ez a cikk a .NET SDK új funkcióit és a .NET 8 eszközkészletét ismerteti.

SDK

Ez a szakasz a következő altopikát tartalmazza:

• CLI-alapú projektértékelés
• Terminál buildkimenete
• Egyszerűsített kimeneti útvonalak
• "dotnet workload clean" parancs
• "dotnet publish" és "dotnet pack" eszközök
• Sablonmotor
• Forráshivatkozás
• Forrás-build SDK

CLI-alapú projektértékelés

Az MSBuild egy új funkciót tartalmaz, amely megkönnyíti az MSBuildből származó adatok beépítése a szkriptekbe vagy eszközökbe. A következő új jelzők érhetők el a CLI-parancsokhoz, például a dotnet publishhez , hogy adatokat szerezzenek be a CI-folyamatokban és máshol való használatra.

Jelölő	Leírás
--getProperty:<PROPERTYNAME>	Lekéri az MSBuild tulajdonságot a megadott névvel.
--getItem:<ITEMTYPE>	Lekéri a megadott típusú MSBuild elemeket.
--getTargetResults:<TARGETNAME>	Lekéri a kimeneteket a megadott cél futtatásából.

Az értékek a standard kimenetre lesznek írva. Több vagy összetett érték kimenete JSON, ahogy az alábbi példákban is látható.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Terminál buildkimenete

dotnet build egy új lehetőséggel modernebb buildkimenetet hozhat létre. Ez a terminálnaplózó kimenete a kapott projekttel kapcsolatos hibákat csoportosítja, jobban megkülönbözteti a többcélos projektek különböző célkereteit, és valós idejű információkat nyújt arról, hogy mit csinál a build. Az új kimenet engedélyezéséhez használja a --tl lehetőséget. Erről a beállításról további információt a dotnet buildelési beállításai között talál.

Egyszerűsített kimeneti útvonalak

A .NET 8 egy olyan lehetőséget vezet be, amely leegyszerűsíti a kimeneti útvonalat és a mappastruktúrát a buildkimenetekhez. A .NET-alkalmazások korábban egy mély és összetett kimeneti útvonalat hoztak létre a különböző buildösszetevőkhöz. Az új, egyszerűsített kimeneti elérésiút-struktúra az összes buildkimenetet egy közös helyre gyűjti, ami megkönnyíti az eszközök előrejelzését.

További információ: Artifacts kimeneti elrendezés.

dotnet workload clean parancs

A .NET 8 egy új parancsot vezet be a több .NET SDK-val vagy Visual Studio-frissítéssel áthagyott számítási feladatcsomagok eltávolításához. Ha problémákba ütközik a számítási feladatok kezelése során, érdemes workload clean lehet biztonságosan visszaállítani egy ismert állapotba, mielőtt újra próbálkozna. A parancsnak két módja van:

• dotnet workload clean

  Futtatja a számítási feladatok szemétgyűjtését fájlalapú vagy MSI-alapú számítási feladatokhoz, amelyek megtisztítják az árva csomagokat. Az árva csomagok a .NET SDK eltávolított verzióiból származnak, vagy olyan csomagokból, amelyekben a csomag telepítési rekordjai már nem léteznek.

  Ha a Visual Studio telepítve van, a parancs felsorolja azokat a számítási feladatokat is, amelyeket manuálisan kell törölnie a Visual Studio használatával.

• dotnet workload clean --all

  Ez a mód agresszívebb, és megtisztítja a gép összes olyan csomagját, amely a jelenlegi SDK számítási feladat telepítési típusa (és ez nem a Visual Studióból származik). Emellett eltávolítja a futó .NET SDK szolgáltatássáv és az alábbi számítási feladatok telepítési rekordjait is.

dotnet publish és dotnet pack eszközök

Mivel a parancsok és dotnet pack a dotnet publish parancsok éles eszközök előállítására szolgálnak, mostantól alapértelmezés szerint eszközöket állítanak előRelease.

Az alábbi kimenet azt mutatja be, hogy a dotnet builddotnet publishtulajdonság falsebeállításával hogyan válthat vissza a közzétételi Debug eszközökre.PublishRelease

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

További információ: "dotnet pack" uses Release config and dotnet publish' uses Release config.

dotnet restore biztonsági naplózás

A .NET 8-tól kezdődően engedélyezheti az ismert biztonsági rések biztonsági ellenőrzését a függőségi csomagok visszaállításakor. Ez a naplózás jelentést készít a biztonsági résekről az érintett csomag nevével, a biztonsági rés súlyosságával és a tanácsadásra mutató hivatkozással további részletekért. Futtatáskor dotnet add vagy dotnet restorea nu1901-NU1904 figyelmeztetések jelennek meg a talált biztonsági résekre vonatkozóan. További információ: Biztonsági rések naplózása.

Sablonmotor

A sablonmotor biztonságosabb felületet biztosít a .NET 8-ban a NuGet biztonsági funkcióinak integrálásával. A fejlesztések az alábbiak:

• Alapértelmezés szerint megakadályozza a csomagok letöltését a hírcsatornákból http:// . A következő parancs például nem fogja telepíteni a sabloncsomagot, mert a forrás URL-címe nem https-t használ.

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  Ezt a korlátozást felülbírálhatja a --force jelölő használatával.

• dotnet new installA dotnet newsabloncsomag ismert biztonsági réseinek keresése és dotnet new updatekeresése. Ha biztonsági réseket talál, és folytatni szeretné a műveletet, használja a jelölőt --force .

• Adja dotnet newmeg a sabloncsomag tulajdonosának adatait. A tulajdonjogot a NuGet portál ellenőrzi, és megbízható jellemzőnek tekinthető.

• dotnet uninstallAzt dotnet search jelzi, hogy egy sablon egy "megbízható" csomagból van-e telepítve– vagyis fenntartott előtagot használ.

Forráshivatkozás

A forráshivatkozás mostantól szerepel a .NET SDK-ban. A cél az, hogy a Source Link SDK-ba való csatlakoztatásával ahelyett, hogy külön <PackageReference> csomagra lenne szükség, a további csomagok alapértelmezés szerint tartalmazzák ezeket az információkat. Ez az információ javítja az IDE-élményt a fejlesztők számára.

Feljegyzés

Ennek a változásnak a mellékhatása, hogy a InformationalVersion véglegesítési információk a beépített kódtárak és alkalmazások értékébe kerülnek, még azok is, amelyek a .NET 7-et vagy egy korábbi verziót célják. További információ: Forráshivatkozás a .NET SDK-ban.

Forrás-build SDK

A Linux disztribúciós (forrás-build) SDK mostantól képes önálló alkalmazások létrehozására a forrás buildelési futtatókörnyezeti csomagok használatával. A disztribúcióspecifikus futtatókörnyezet-csomag a forrás-build SDK-val van csomagolva. Az önálló üzembe helyezés során a rendszer hivatkozni fog erre a csomagban található futtatókörnyezeti csomagra, ezáltal lehetővé téve a szolgáltatást a felhasználók számára.

Natív AOT-támogatás

A natív AOT-ként való közzététel lehetőségét először a .NET 7-ben vezették be. Ha natív AOT használatával tesz közzé egy alkalmazást, az alkalmazás egy teljesen önálló verzióját hozza létre, amely nem igényel futtatókörnyezetet – minden megtalálható egyetlen fájlban. A .NET 8 a natív AOT-közzététel következő fejlesztéseit biztosítja:

• Támogatja az x64- és Arm64-architektúrákat macOS rendszeren.

• Akár 50%-kal csökkenti a natív AOT-alkalmazások méretét Linuxon. Az alábbi táblázat egy natív AOT-val közzétett ""Helló világ!" alkalmazás" alkalmazás méretét mutatja, amely a .NET 7 és a .NET 8 teljes .NET-futtatókörnyezetét tartalmazza:

  Operációs rendszer	.NET 7	.NET 8
  Linux x64 (a -p:StripSymbols=true)	3,76 MB	1,84 MB
  Windows x64	2,85 MB	1,77 MB

• Lehetővé teszi az optimalizálási beállítások megadását: méret vagy sebesség. Alapértelmezés szerint a fordító úgy dönt, hogy gyors kódot hoz létre az alkalmazás méretének figyelembevételével. Az MSBuild tulajdonság használatával <OptimizationPreference> azonban kifejezetten az egyik vagy a másikra optimalizálhat. További információ: AOT-környezetek optimalizálása.

Konzolalkalmazás-sablon

Az alapértelmezett konzolalkalmazás-sablon mostantól támogatja a beépített AOT-t. Az AOT-fordításhoz konfigurált projekt létrehozásához futtassa a következőt dotnet new console --aot: A hozzáadott --aot projektkonfiguráció három effektussal rendelkezik:

• Natív, önálló végrehajtható fájlt hoz létre natív AOT használatával, amikor közzéteszi a projektet, például a Visual Studióval vagy a Visual Studióval dotnet publish .
• Lehetővé teszi a kompatibilitás-elemzőket a vágáshoz, az AOT-hoz és az egy fájlhoz. Ezek az elemzők a projekt potenciálisan problémás részeire figyelmeztetik (ha vannak ilyenek).
• Lehetővé teszi az AOT hibakeresési időalapú emulációját, így ha AOT-fordítás nélkül hibakeresést hajtanak létre a projektben, az AOT-hoz hasonló felületet kap. Ha például olyan NuGet-csomagban használja System.Reflection.Emit , amelyet nem jegyzetelt meg az AOT-hoz (ezért a kompatibilitás-elemző kihagyta), az emuláció azt jelenti, hogy nem lesz meglepetése, amikor megpróbálja közzétenni a projektet az AOT használatával.

iOS-szerű platformok megcélzása natív AOT használatával

A .NET 8 megkezdi a natív AOT-támogatás engedélyezését az iOS-hez hasonló platformokon. Most már a natív AOT-val hozhat létre és futtathat .NET iOS- és .NET MAUI-alkalmazásokat a következő platformokon:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Az előzetes vizsgálatok azt mutatják, hogy a lemezen lévő alkalmazás mérete körülbelül 35%-kal csökken az olyan .NET iOS-alkalmazások esetében, amelyek natív AOT-t használnak a Mono helyett. Az alkalmazás mérete a .NET MAUI iOS-alkalmazások lemezén akár 50%-kal is csökken. Emellett az indítási idő is gyorsabb. A .NET iOS-alkalmazások indítási ideje körülbelül 28%-kal gyorsabb, míg a .NET MAUI iOS-alkalmazások 50%-kal jobb indítási teljesítménnyel rendelkeznek a Mono-hoz képest. A .NET 8 támogatása kísérleti jellegű, és csak a funkció egészének első lépése. További információkért lásd a .NET 8 teljesítménybeli fejlesztéseit a .NET MAUI blogbejegyzésében.

Natív AOT-támogatás érhető el az alkalmazás üzembe helyezésére szánt bejelentkezési funkcióként; Továbbra is a Mono az alkalmazásfejlesztés és -üzembe helyezés alapértelmezett futtatókörnyezete. Ha .NET MAUI-alkalmazást szeretne létrehozni és futtatni natív AOT használatával egy iOS-eszközön, telepítse a .NET MAUI számítási feladatot, dotnet workload install maui és dotnet new maui -n HelloMaui hozza létre az alkalmazást. Ezután állítsa az MSBuild tulajdonságot PublishAottrue a projektfájlba.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Ha beállítja a szükséges tulajdonságot, és az alábbi példában látható módon fut dotnet publish , az alkalmazás natív AOT használatával lesz üzembe helyezve.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Korlátozások

Nem minden iOS-funkció kompatibilis a natív AOT-jal. Hasonlóképpen, az iOS-ben gyakran használt kódtárak nem kompatibilisek a NativeAOT-tal. A natív AOT-telepítés meglévő korlátai mellett az alábbi lista az iOS-hez hasonló platformokra vonatkozó egyéb korlátozásokat is tartalmazza:

• A natív AOT használata csak az alkalmazás üzembe helyezésedotnet publish () során engedélyezett.
• A felügyelt kódkeresést csak a Mono támogatja.
• A .NET MAUI-keretrendszerrel való kompatibilitás korlátozott.

AOT-fordítás Android-alkalmazásokhoz

Az alkalmazások méretének csökkentése érdekében az Androidot megcélzó .NET- és .NET MAUI-alkalmazások profilalapú, előzetes (AOT) fordítási módot használnak a kiadási módban való használatukkor. A profilozott AOT-fordítás kevesebb módszert érint, mint a hagyományos AOT-fordítás. A .NET 8 bevezeti azt a <AndroidStripILAfterAOT> tulajdonságot, amely lehetővé teszi, hogy az Android-alkalmazásokhoz készült AOT-fordítással még nagyobb mértékben csökkentse az alkalmazás méretét.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

Alapértelmezés szerint AndroidStripILAfterAOTtrue az alapértelmezett AndroidEnableProfiledAot beállítás felülbírálása lehetővé teszi (majdnem) az AOT által lefordított metódusok kivágását. Profilozott AOT és IL sztriptízelést is használhat, ha mindkét tulajdonságot explicit módon a következőre trueállítja:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Többszintű Windows-alkalmazások

Ha olyan alkalmazásokat hoz létre, amelyek a Windowst nem Windows-platformokon célják meg, az eredményként kapott végrehajtható fájl mostantól frissül a megadott Win32-erőforrásokkal – például alkalmazásikonnal, jegyzékfájlokkal és verzióinformációkkal.

Korábban az alkalmazásokat windowsosra kellett építeni, hogy ilyen erőforrásokkal rendelkezzenek. A keresztépítési támogatás terén fennálló rés javítása népszerű kérés volt, mivel jelentős fájdalompont volt, amely hatással volt az infrastruktúra összetettségére és az erőforrás-használatra is.

.NET Linuxon

Minimális támogatási alapkonfigurációk Linuxhoz

A Linux minimális támogatási alapkonfigurációi frissültek a .NET 8-hoz. A .NET az Ubuntu 16.04-et célozza meg minden architektúrához. Ez elsősorban a .NET 8 minimális glibc verziójának meghatározásához fontos. A .NET 8 nem indul el olyan disztribúciós verziókon, amelyek régebbi glibc-t tartalmaznak, például az Ubuntu 14.04-et vagy a Red Hat Enterprise Linux 7-et.

További információ: Red Hat Enterprise Linux Family támogatás.

Saját .NET létrehozása Linuxon

A korábbi .NET-verziókban létrehozhatta a .NET-et a forrásból, de ehhez létre kellett hoznia egy "source tarball" fájlt a dotnet/installer adattár véglegesítéséből, amely megfelel egy kiadásnak. A .NET 8-ban ez már nem szükséges, és közvetlenül a dotnet/dotnet-adattárból hozhat létre .NET-et Linuxon. Ez az adattár a dotnet/source-build használatával készít .NET-futtatókörnyezeteket, eszközöket és SDK-kat. Ez ugyanaz a build, mint a Red Hat és a Canonical a .NET létrehozásához.

A legtöbb ember számára a legegyszerűbb módszer a tárolóban való építés, mivel a dotnet-buildtools/prereqs tárolórendszerképek tartalmazzák az összes szükséges függőséget. További információkért tekintse meg a buildelési utasításokat.

NuGet-aláírás ellenőrzése

A .NET 8-tól kezdve a NuGet alapértelmezés szerint ellenőrzi az aláírt csomagokat Linuxon. A NuGet továbbra is ellenőrzi az aláírt csomagokat Windows rendszeren is.

A felhasználók többsége nem veszi észre az ellenőrzést. Ha azonban rendelkezik egy meglévő főtanúsítvány-csomaggal, amely a /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem címen található, akkor az NU3042 figyelmeztetéssel kísért megbízhatósági hibák jelentkezhetnek.

Az ellenőrzés letiltásához állítsa be a környezeti változót DOTNET_NUGET_SIGNATURE_VERIFICATION a következőre false: .

Kódelemzés

A .NET 8 számos új kódelemzőt és -javítást tartalmaz annak ellenőrzéséhez, hogy helyesen és hatékonyan használja-e a .NET-kódtár API-kat. Az alábbi táblázat az új elemzőket foglalja össze.

Szabályazonosító	Kategória	Leírás
CA1856	Teljesítmény	Akkor aktiválódik, ha az ConstantExpectedAttribute attribútum nincs megfelelően alkalmazva egy paraméterre.
CA1857	Teljesítmény	Akkor aktiválódik, ha egy paraméter megjegyzésekkel ConstantExpectedAttribute van ellátva, de a megadott argumentum nem állandó.
CA1858	Teljesítmény	Annak megállapításához, hogy egy sztring egy adott előtaggal kezdődik-e, jobb meghívni String.StartsWith , mint meghívni String.IndexOf , majd összehasonlítani az eredményt nullával.
CA1859	Teljesítmény	Ez a szabály azt javasolja, hogy lehetőség szerint frissítse az adott helyi változók, mezők, tulajdonságok, metódusparaméterek és metódus-visszatérési típusok típusát az interfészről vagy az absztrakt típusról a konkrét típusokra. A konkrét típusok használata jobb minőségű generált kódhoz vezet.
CA1860	Teljesítmény	Annak meghatározásához, hogy egy gyűjteménytípus rendelkezik-e elemekkel, jobb, ha a parancsot használja Length, Countvagy IsEmpty nem hívja Enumerable.Anymeg.
CA1861	Teljesítmény	Az argumentumként átadott állandó tömbök nem lesznek újra felhasználva, ha ismételten meghívják őket, ami azt jelenti, hogy minden alkalommal új tömb jön létre. A teljesítmény javítása érdekében érdemes lehet kinyerni a tömböt egy statikus írásvédett mezőre.
CA1865-CA1867	Teljesítmény	A karakter túlterhelése jobb teljesítményű túlterhelés egyetlen karakterrel rendelkező sztring esetében.
CA2021	Megbízhatóság	Enumerable.Cast<TResult>(IEnumerable) és Enumerable.OfType<TResult>(IEnumerable) kompatibilis típusokat igényel a megfelelő működéshez. Az általános típusok nem támogatják a szélesítést és a felhasználó által definiált konverziókat.
CA1510-CA1513	Karbantarthatóság	A dobás segítői egyszerűbbek és hatékonyabbak, mint egy if új kivételpéldányt építő blokkok. Ez a négy elemző a következő kivételekhez lett létrehozva: ArgumentNullException, ArgumentOutOfRangeExceptionArgumentExceptionés ObjectDisposedException.

Diagnosztika

A C# gyakori újratöltése támogatja az általános elemek módosítását

A .NET 8-tól kezdve a C# Hot Reload támogatja az általános típusok és az általános metódusok módosítását. Ha a Visual Studióval hibakeresést hajt végre konzol-, asztali, mobil- vagy WebAssembly-alkalmazásokban, a C#-kódban vagy Razor-oldalakon alkalmazhatja az általános osztályok és általános metódusok módosításait. További információkért tekintse meg a Roslyn által támogatott módosítások teljes listáját.

Lásd még

• A .NET 8 újdonságai