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 build
dotnet publish
tulajdonság false
beá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 restore
a 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 install
Adotnet new
sabloncsomag ismert biztonsági réseinek keresése ésdotnet new update
keresése. Ha biztonsági réseket talál, és folytatni szeretné a műveletet, használja a jelölőt--force
.Adja
dotnet new
meg a sabloncsomag tulajdonosának adatait. A tulajdonjogot a NuGet portál ellenőrzi, és megbízható jellemzőnek tekinthető.dotnet uninstall
Aztdotnet 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 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ése
dotnet 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.
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 , Count vagy 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, ArgumentOutOfRangeException ArgumentExceptioné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.