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.

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 build dotnet 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.

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 PublishAot true 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 AndroidStripILAfterAOT true 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.

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