Wat is er nieuw in de SDK en hulpprogramma's voor .NET 8

In dit artikel worden nieuwe functies in de .NET SDK en hulpprogramma's voor .NET 8 beschreven.

SDK

Deze sectie bevat de volgende subonderwerpen:

• Op CLI gebaseerde projectevaluatie
• Uitvoer van terminalbuild
• Vereenvoudigde uitvoerpaden
• Opdracht 'dotnet workload clean'
• Assets 'dotnet publish' en 'dotnet pack'
• Sjabloonengine
• Bronkoppeling
• Source-build-SDK

Op CLI gebaseerde projectevaluatie

MSBuild bevat een nieuwe functie waarmee u eenvoudiger gegevens van MSBuild kunt opnemen in uw scripts of hulpprogramma's. De volgende nieuwe vlaggen zijn beschikbaar voor CLI-opdrachten zoals dotnet publish om gegevens te verkrijgen voor gebruik in CI-pijplijnen en elders.

Vlag	Beschrijving
--getProperty:<PROPERTYNAME>	Haalt de MSBuild-eigenschap op met de opgegeven naam.
--getItem:<ITEMTYPE>	Hiermee worden MSBuild-items van het opgegeven type opgehaald.
--getTargetResults:<TARGETNAME>	Haalt de uitvoer op van het uitvoeren van het opgegeven doel.

Waarden worden naar de standaarduitvoer geschreven. Meerdere of complexe waarden worden uitgevoerd als JSON, zoals wordt weergegeven in de volgende voorbeelden.

>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",
        ...
    ]
  }
}

Uitvoer van terminalbuild

dotnet build heeft een nieuwe optie om meer gemoderniseerde build-uitvoer te produceren. Deze terminalloggeruitvoergroepeert fouten met het project waaruit ze afkomstig zijn, maakt beter onderscheid tussen de verschillende doelframeworks voor projecten met meerdere doelen en biedt realtime informatie over wat de build doet. Als u wilt kiezen voor de nieuwe uitvoer, gebruikt u de --tl optie. Zie dotnet-buildopties voor meer informatie over deze optie.

Vereenvoudigde uitvoerpaden

.NET 8 introduceert een optie om het uitvoerpad en de mapstructuur voor build-uitvoer te vereenvoudigen. Voorheen maakten .NET-apps een diepe en complexe set uitvoerpaden voor verschillende buildartefacten. De nieuwe, vereenvoudigde structuur van het uitvoerpad verzamelt alle build-uitvoer op een gemeenschappelijke locatie, waardoor het gemakkelijker is om te anticiperen op hulpprogramma's.

Zie de indeling Artefacten-uitvoer voor meer informatie.

dotnet workload clean opdracht

.NET 8 introduceert een nieuwe opdracht voor het opschonen van workloadpakketten die mogelijk worden overgelaten via verschillende .NET SDK- of Visual Studio-updates. Als u problemen ondervindt bij het beheren van workloads, kunt u overwegen workload clean om veilig te herstellen naar een bekende status voordat u het opnieuw probeert. De opdracht heeft twee modi:

• dotnet workload clean

  Voert garbagecollection van werkbelastingen uit voor werkbelastingen op basis van bestanden of MSI-workloads, waarmee zwevende pakketten worden opgeschoond. Zwevende pakketten zijn afkomstig van verwijderde versies van de .NET SDK of packs waarbij installatierecords voor het pakket niet meer bestaan.

  Als Visual Studio is geïnstalleerd, worden met de opdracht ook alle werkbelastingen vermeld die u handmatig moet opschonen met Behulp van Visual Studio.

• dotnet workload clean --all

  Deze modus is agressiever en schoont elk pakket op de computer op van het huidige installatietype SDK-workload (en dat is niet van Visual Studio). Ook worden alle workloadinstallatierecords voor de actieve .NET SDK-functieband en hieronder verwijderd.

dotnet publish en dotnet pack assets

Omdat de dotnet publish opdrachten dotnet pack bedoeld zijn om productieassets te produceren, produceren Release ze nu standaard assets.

In de volgende uitvoer ziet u het verschillende gedrag tussen dotnet build en, en hoe u kunt terugkeren naar het publiceren van Debug assets door de PublishRelease eigenschap in te stellen op falsedotnet publish.

/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/

Zie 'dotnet pack' maakt gebruik van releaseconfiguratie en 'dotnet publish' maakt gebruik van releaseconfiguratie.

dotnet restore beveiligingscontrole

Vanaf .NET 8 kunt u kiezen voor beveiligingscontroles op bekende beveiligingsproblemen wanneer afhankelijkheidspakketten worden hersteld. Deze controle produceert een rapport van beveiligingsproblemen met de naam van het getroffen pakket, de ernst van het beveiligingsprobleem en een koppeling naar het advies voor meer informatie. Wanneer u uitvoert dotnet add of dotnet restore, worden waarschuwingen NU1901-NU1904 weergegeven voor eventuele gevonden beveiligingsproblemen. Zie Controleren op beveiligingsproblemen voor meer informatie.

Sjabloonengine

De sjabloonengine biedt een veiligere ervaring in .NET 8 door enkele beveiligingsfuncties van NuGet te integreren. De verbeteringen zijn onder andere:

• Voorkom dat pakketten standaard worden gedownload van http:// feeds. Met de volgende opdracht kan het sjabloonpakket bijvoorbeeld niet worden geïnstalleerd omdat de bron-URL geen HTTPS gebruikt.

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

  U kunt deze beperking overschrijven met behulp van de --force vlag.

• Controleer dotnet newop bekende beveiligingsproblemen in het sjabloonpakket voor , dotnet new installen dotnet new updatecontroleer deze. Als er beveiligingsproblemen worden gevonden en u wilt doorgaan, moet u de --force vlag gebruiken.

• Geef dotnet newinformatie op over de eigenaar van het sjabloonpakket. Eigendom wordt geverifieerd door de NuGet-portal en kan worden beschouwd als een betrouwbaar kenmerk.

• dotnet uninstallGeef dotnet search aan of een sjabloon is geïnstalleerd vanuit een pakket dat 'vertrouwd' is, dat wil gezegd, er wordt een gereserveerd voorvoegsel gebruikt.

Bronkoppeling

Source Link is nu opgenomen in de .NET SDK. Het doel is dat door bronkoppeling te bundelen in de SDK, in plaats van een afzonderlijk <PackageReference> pakket te vereisen, meer pakketten deze informatie standaard bevatten. Deze informatie verbetert de IDE-ervaring voor ontwikkelaars.

Notitie

Als neveneffect van deze wijziging wordt doorvoerinformatie opgenomen in de InformationalVersion waarde van ingebouwde bibliotheken en toepassingen, zelfs die gericht zijn op .NET 7 of een eerdere versie. Zie Source Link opgenomen in de .NET SDK voor meer informatie.

Source-build-SDK

De linux-distributie-SDK (source-build) biedt nu de mogelijkheid om zelfstandige toepassingen te bouwen met behulp van de runtimepakketten voor source-build. Het distributiespecifieke runtimepakket wordt gebundeld met de source-build SDK. Tijdens de zelfstandige implementatie wordt naar dit gebundelde runtimepakket verwezen, waardoor de functie voor gebruikers wordt ingeschakeld.

Systeemeigen AOT-ondersteuning

De optie voor publiceren als systeemeigen AOT is voor het eerst geïntroduceerd in .NET 7. Als u een app publiceert met Native AOT, wordt er een volledig zelfstandige versie van uw app gemaakt die geen runtime nodig heeft. Alles is opgenomen in één bestand. .NET 8 brengt de volgende verbeteringen aan systeemeigen AOT-publicatie:

• Voegt ondersteuning toe voor de x64- en Arm64-architecturen in macOS.

• Vermindert de grootte van systeemeigen AOT-apps op Linux met maximaal 50%. In de volgende tabel ziet u de grootte van een 'Hallo wereld'-app die is gepubliceerd met Native AOT, met daarin de volledige .NET-runtime op .NET 7 versus .NET 8:

  Besturingssysteem	.NET 7	.NET 8
  Linux x64 (met -p:StripSymbols=true)	3,76 MB	1,84 MB
  Windows x64	2,85 MB	1,77 MB

• Hiermee kunt u een optimalisatievoorkeur opgeven: grootte of snelheid. Standaard kiest de compiler ervoor om snelle code te genereren terwijl u rekening houdt met de grootte van de toepassing. U kunt echter de <OptimizationPreference> eigenschap MSBuild gebruiken om specifiek voor een of de andere te optimaliseren. Zie AOT-implementaties optimaliseren voor meer informatie.

Console-app-sjabloon

De standaardsjabloon voor console-apps bevat nu ondersteuning voor AOT-out-of-the-box. Als u een project wilt maken dat is geconfigureerd voor AOT-compilatie, voert u gewoon uit dotnet new console --aot. De projectconfiguratie die door is --aot toegevoegd, heeft drie effecten:

• Genereert een systeemeigen, zelfstandig uitvoerbaar bestand met Systeemeigen AOT wanneer u het project publiceert, bijvoorbeeld met dotnet publish of Visual Studio.
• Hiermee schakelt u compatibiliteitsanalyses in voor bijsnijden, AOT en één bestand. Met deze analyses wordt u gewaarschuwd voor mogelijk problematische onderdelen van uw project (indien aanwezig).
• Schakelt foutopsporingstijd emulatie van AOT in, zodat wanneer u fouten in uw project opssport zonder AOT-compilatie, u een vergelijkbare ervaring krijgt als AOT. Als u bijvoorbeeld gebruikt System.Reflection.Emit in een NuGet-pakket dat niet is geannoteerd voor AOT (en daarom is gemist door de compatibiliteitsanalyse), betekent de emulatie dat u geen verrassingen hebt wanneer u het project probeert te publiceren met AOT.

IOS-achtige platforms targeten met systeemeigen AOT

.NET 8 start het werk om systeemeigen AOT-ondersteuning in te schakelen voor iOS-achtige platforms. U kunt nu .NET iOS- en .NET SDK-toepassingen bouwen en uitvoeren met Native AOT op de volgende platforms:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Voorlopige tests laten zien dat de app-grootte op schijf met ongeveer 35% afneemt voor .NET iOS-apps die systeemeigen AOT gebruiken in plaats van Mono. De app-grootte op schijf voor .NET MAUI iOS-apps neemt tot 50% af. Daarnaast is de opstarttijd ook sneller. .NET iOS-apps hebben ongeveer 28% snellere opstarttijd, terwijl .NET MAUI iOS-apps ongeveer 50% betere opstartprestaties hebben in vergelijking met Mono. De .NET 8-ondersteuning is experimenteel en alleen de eerste stap voor de functie als geheel. Zie de blogpost .NET 8 Performance Improvements in .NET MAUI voor meer informatie.

Systeemeigen AOT-ondersteuning is beschikbaar als een opt-in-functie die is bedoeld voor app-implementatie; Mono is nog steeds de standaardruntime voor het ontwikkelen en implementeren van apps. Als u een .NETLOAD-toepassing wilt bouwen en uitvoeren met Native AOT op een iOS-apparaat, gebruikt dotnet workload install maui u om de .NETLOAD-workload te installeren en dotnet new maui -n HelloMaui de app te maken. Stel vervolgens de eigenschap PublishAottrue MSBuild in op in het projectbestand.

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

Wanneer u de vereiste eigenschap instelt en uitvoert dotnet publish zoals wordt weergegeven in het volgende voorbeeld, wordt de app geïmplementeerd met behulp van systeemeigen AOT.

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

Beperkingen

Niet alle iOS-functies zijn compatibel met Systeemeigen AOT. Op dezelfde manier zijn niet alle bibliotheken die vaak worden gebruikt in iOS compatibel met NativeAOT. Naast de bestaande beperkingen van systeemeigen AOT-implementatie worden in de volgende lijst enkele van de andere beperkingen weergegeven bij het instellen van iOS-achtige platforms:

• Het gebruik van systeemeigen AOT is alleen ingeschakeld tijdens de implementatie van de app (dotnet publish).
• Foutopsporing van beheerde code wordt alleen ondersteund met Mono.
• De compatibiliteit met het .NET MAUI-framework is beperkt.

AOT-compilatie voor Android-apps

Als u de grootte van apps wilt verkleinen, gebruiken .NET- en .NET-APPS die gericht zijn op Android , de compilatiemodus vooraf geprofileerd (AOT) wanneer ze zijn ingebouwd in de releasemodus. Geprofileerde AOT-compilatie beïnvloedt minder methoden dan reguliere AOT-compilatie. .NET 8 introduceert de <AndroidStripILAfterAOT> eigenschap waarmee u zich kunt aanmelden voor verdere AOT-compilatie voor Android-apps om de app nog groter te maken.

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

Als u AndroidStripILAfterAOT de standaardinstelling AndroidEnableProfiledAot wilt true overschrijven, kunnen (bijna) alle methoden die door AOT zijn gecompileerd, worden ingekort. U kunt ook geprofileerde AOT- en IL-stripping samen gebruiken door beide eigenschappen expliciet in te stellen op true:

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

Ingebouwde Windows-apps

Wanneer u apps bouwt die gericht zijn op Windows op niet-Windows-platforms, wordt het resulterende uitvoerbare bestand nu bijgewerkt met opgegeven Win32-resources, bijvoorbeeld toepassingspictogram, manifest, versie-informatie.

Voorheen moesten toepassingen worden gebouwd op Windows om dergelijke resources te kunnen hebben. Het oplossen van deze kloof in ondersteuning voor meerdere gebouwen is een populaire aanvraag geweest, omdat het een belangrijk pijnpunt was dat zowel de complexiteit van de infrastructuur als het resourcegebruik beïnvloedde.

.NET in Linux

Minimale ondersteuningsbasislijnen voor Linux

De minimale ondersteuningsbasislijnen voor Linux zijn bijgewerkt voor .NET 8. .NET is gebouwd voor Ubuntu 16.04, voor alle architecturen. Dat is vooral belangrijk voor het definiëren van de minimumversie glibc voor .NET 8. .NET 8 kan niet worden gestart op distributieversies met een oudere glibc, zoals Ubuntu 14.04 of Red Hat Enterprise Linux 7.

Zie Ondersteuning voor Red Hat Enterprise Linux Family voor meer informatie.

Uw eigen .NET bouwen in Linux

In eerdere .NET-versies kunt u .NET bouwen op basis van de bron, maar u moet een 'bron tarball' maken vanuit de dotnet-/installer-opslagplaatsdoorvoering die overeenkomt met een release. In .NET 8 is dat niet meer nodig en kunt u .NET rechtstreeks vanuit de dotnet/dotnet-opslagplaats bouwen op Linux. Deze opslagplaats maakt gebruik van dotnet/source-build om .NET-runtimes, hulpprogramma's en SDK's te bouwen. Dit is dezelfde build die Red Hat en Canonical gebruiken om .NET te bouwen.

Bouwen in een container is de eenvoudigste benadering voor de meeste mensen, omdat de dotnet-buildtools/prereqs containerinstallatiekopieën alle vereiste afhankelijkheden bevatten. Zie de build-instructies voor meer informatie.

NuGet-handtekeningverificatie

Vanaf .NET 8 controleert NuGet standaard ondertekende pakketten op Linux. NuGet blijft ook ondertekende pakketten controleren in Windows.

De meeste gebruikers moeten de verificatie niet opmerken. Als u echter een bestaande basiscertificaatbundel hebt die zich bevindt op /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, ziet u mogelijk vertrouwensfouten, vergezeld van waarschuwing NU3042.

U kunt zich afmelden voor verificatie door de omgevingsvariabele DOTNET_NUGET_SIGNATURE_VERIFICATION in te stellen op false.

Codeanalyse

.NET 8 bevat verschillende nieuwe codeanalyses en fixers om te controleren of u .NET-bibliotheek-API's correct en efficiënt gebruikt. De volgende tabel bevat een overzicht van de nieuwe analyses.

Regel-id	Categorie	Beschrijving
CA1856	Prestaties	Wordt geactiveerd wanneer het ConstantExpectedAttribute kenmerk niet correct wordt toegepast op een parameter.
CA1857	Prestaties	Wordt geactiveerd wanneer een parameter wordt geannoteerd met ConstantExpectedAttribute maar het opgegeven argument geen constante is.
CA1858	Prestaties	Als u wilt bepalen of een tekenreeks begint met een bepaald voorvoegsel, is het beter om aan te roepen String.StartsWith dan aan te roepen String.IndexOf en vervolgens het resultaat te vergelijken met nul.
CA1859	Prestaties	Deze regel raadt u aan het type specifieke lokale variabelen, velden, eigenschappen, methodeparameters en methode-retourtypen bij te voeren van interface- of abstracte typen naar concrete typen, indien mogelijk. Het gebruik van betontypen leidt tot een hogere kwaliteit gegenereerde code.
CA1860	Prestaties	Om te bepalen of een verzamelingstype elementen bevat, is het beter om te gebruiken Length, Countof IsEmpty dan aan te roepen Enumerable.Any.
CA1861	Prestaties	Constante matrices die worden doorgegeven als argumenten worden niet opnieuw gebruikt wanneer ze herhaaldelijk worden aangeroepen, wat impliceert dat er telkens een nieuwe matrix wordt gemaakt. U kunt de prestaties verbeteren door de matrix te extraheren naar een statisch alleen-lezen veld.
CA1865-CA1867	Prestaties	De overbelasting van het teken is een beter presterende overbelasting voor een tekenreeks met één teken.
CA2021	Betrouwbaarheid	Enumerable.Cast<TResult>(IEnumerable) en Enumerable.OfType<TResult>(IEnumerable) vereisen dat compatibele typen correct functioneren. Widening en door de gebruiker gedefinieerde conversies worden niet ondersteund met algemene typen.
CA1510-CA1513	Onderhoud	Throw helpers zijn eenvoudiger en efficiënter dan een if blok dat een nieuwe uitzonderingsexemplaren samenbouwt. Deze vier analyseanalyses zijn gemaakt voor de volgende uitzonderingen: ArgumentNullException, ArgumentExceptionen ObjectDisposedExceptionArgumentOutOfRangeException .

Diagnostiek

C# Hot Reload biedt ondersteuning voor het wijzigen van generics

Vanaf .NET 8 ondersteunt C# Hot Reload het wijzigen van algemene typen en algemene methoden. Wanneer u fouten in de console, desktop, mobiel of WebAssembly-toepassingen met Visual Studio opssport, kunt u wijzigingen toepassen op algemene klassen en algemene methoden in C#-code of Razor-pagina's. Zie de volledige lijst met bewerkingen die door Roslyn worden ondersteund voor meer informatie.

Zie ook

• Nieuw in .NET 8