Co nowego w zestawie SDK i narzędziach dla platformy .NET 8

W tym artykule opisano nowe funkcje w zestawie .NET SDK i narzędziach dla platformy .NET 8.

SDK

Ta sekcja zawiera następujące podtopy:

• Ocena projektu oparta na interfejsie wiersza polecenia
• Dane wyjściowe kompilacji terminalu
• Uproszczone ścieżki wyjściowe
• Polecenie "dotnet workload clean"
• Zasoby "dotnet publish" i "dotnet pack"
• Aparat szablonów
• Link do źródła
• Zestaw SDK kompilacji źródłowej

Ocena projektu oparta na interfejsie wiersza polecenia

Program MSBuild zawiera nową funkcję, która ułatwia dołączanie danych z programu MSBuild do skryptów lub narzędzi. Następujące nowe flagi są dostępne dla poleceń interfejsu wiersza polecenia, takich jak dotnet publish , aby uzyskać dane do użycia w potokach ciągłej integracji i gdzie indziej.

Flaga	opis
--getProperty:<PROPERTYNAME>	Pobiera właściwość MSBuild o określonej nazwie.
--getItem:<ITEMTYPE>	Pobiera elementy MSBuild określonego typu.
--getTargetResults:<TARGETNAME>	Pobiera dane wyjściowe z uruchamiania określonego obiektu docelowego.

Wartości są zapisywane w standardowych danych wyjściowych. Wiele lub złożone wartości są danymi wyjściowymi w formacie JSON, jak pokazano w poniższych przykładach.

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

Dane wyjściowe kompilacji terminalu

dotnet build Ma nową opcję tworzenia bardziej zmodernizowanych danych wyjściowych kompilacji. Ten rejestrator terminalu grupuje błędy związane z projektem, z którego pochodzą, lepiej odróżnia różne struktury docelowe dla projektów wielokierunkowych i udostępnia informacje w czasie rzeczywistym o tym, co robi kompilacja. Aby wyrazić zgodę na nowe dane wyjściowe, użyj --tl opcji . Aby uzyskać więcej informacji na temat tej opcji, zobacz dotnet build options (Opcje kompilacji dotnet).

Uproszczone ścieżki wyjściowe

Platforma .NET 8 wprowadza opcję uproszczenia struktury ścieżki wyjściowej i folderu dla danych wyjściowych kompilacji. Wcześniej aplikacje platformy .NET stworzyły głęboki i złożony zestaw ścieżek wyjściowych dla różnych artefaktów kompilacji. Nowa, uproszczona struktura ścieżek wyjściowych zbiera wszystkie dane wyjściowe kompilacji w wspólną lokalizację, co ułatwia przewidywanie narzędzi.

Aby uzyskać więcej informacji, zobacz Układ danych wyjściowych artefaktów.

dotnet workload clean polecenie

Platforma .NET 8 wprowadza nowe polecenie służące do czyszczenia pakietów obciążeń, które mogą zostać pozostawione za pomocą kilku aktualizacji zestawu .NET SDK lub programu Visual Studio. Jeśli podczas zarządzania obciążeniami wystąpią problemy, rozważ użycie polecenia workload clean w celu bezpiecznego przywrócenia do znanego stanu przed ponowną próbą. Polecenie ma dwa tryby:

• dotnet workload clean

  Uruchamia odzyskiwanie pamięci obciążenia dla obciążeń opartych na plikach lub msi, które czyści oddzielone pakiety. Oddzielone pakiety pochodzą z odinstalowanych wersji zestawu .NET SDK lub pakietów, w których rekordy instalacji pakietu już nie istnieją.

  Jeśli program Visual Studio jest zainstalowany, polecenie wyświetla również listę wszystkich obciążeń, które należy wyczyścić ręcznie przy użyciu programu Visual Studio.

• dotnet workload clean --all

  Ten tryb jest bardziej agresywny i czyści każdy pakiet na maszynie, która jest bieżącym typem instalacji obciążenia zestawu SDK (a nie z programu Visual Studio). Usuwa również wszystkie rekordy instalacji obciążenia dla uruchomionego zespołu funkcji zestawu SDK platformy .NET i poniżej.

dotnet publish i dotnet pack elementy zawartości

dotnet publish Ponieważ polecenia i dotnet pack są przeznaczone do tworzenia zasobów produkcyjnych, domyślnie generują Release zasoby.

W poniższych danych wyjściowych przedstawiono różne zachowanie między elementami i oraz sposób przywracania do publikowania PublishReleaseDebug zasobów przez ustawienie właściwości na false.dotnet publishdotnet build

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

Aby uzyskać więcej informacji, zobacz "dotnet pack" używa konfiguracji wydania i polecenia "dotnet publish" używa konfiguracji wydania.

dotnet restore inspekcja zabezpieczeń

Począwszy od platformy .NET 8, możesz zdecydować się na sprawdzanie zabezpieczeń pod kątem znanych luk w zabezpieczeniach po przywróceniu pakietów zależności. Ta inspekcja generuje raport luk w zabezpieczeniach z nazwą pakietu, ważnością luki w zabezpieczeniach i linkiem do porady, aby uzyskać więcej szczegółów. Po uruchomieniu dotnet add programu lub dotnet restoreostrzeżenia NU1901-NU1904 będą wyświetlane dla wszystkich znalezionych luk w zabezpieczeniach. Aby uzyskać więcej informacji, zobacz Inspekcja pod kątem luk w zabezpieczeniach.

Aparat szablonów

Aparat szablonów zapewnia bezpieczniejsze środowisko na platformie .NET 8 dzięki integracji niektórych funkcji związanych z zabezpieczeniami nuGet. Ulepszenia obejmują:

• Zapobiegaj pobieraniu pakietów z http:// kanałów informacyjnych domyślnie. Na przykład następujące polecenie nie spowoduje zainstalowania pakietu szablonu, ponieważ źródłowy adres URL nie używa protokołu HTTPS.

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

  To ograniczenie można zastąpić za pomocą flagi --force .

• W przypadku dotnet newplików , dotnet new installi dotnet new updatesprawdź znane luki w zabezpieczeniach w pakiecie szablonu. Jeśli znaleziono luki w zabezpieczeniach i chcesz kontynuować, musisz użyć flagi --force .

• W przypadku dotnet newprogramu podaj informacje o właścicielu pakietu szablonu. Własność jest weryfikowana przez portal NuGet i może być traktowana jako godna zaufania cecha.

• W przypadku dotnet search elementów i dotnet uninstallwskaż, czy szablon jest instalowany z pakietu "zaufanego", czyli używa prefiksu zarezerwowanego.

Link do źródła

Link źródłowy jest teraz dołączony do zestawu .NET SDK. Celem jest to, że przez łączenie linku źródłowego z zestawem SDK, zamiast wymagać oddzielnego <PackageReference> pakietu, więcej pakietów będzie domyślnie zawierać te informacje. Te informacje poprawią środowisko IDE dla deweloperów.

Uwaga

Jako efekt uboczny tej zmiany informacje o zatwierdzeniu są uwzględniane w InformationalVersion wartości skompilowanych bibliotek i aplikacji, nawet tych, które są przeznaczone dla platformy .NET 7 lub starszej wersji. Aby uzyskać więcej informacji, zobacz Link źródłowy uwzględniony w zestawie SDK platformy .NET.

Zestaw SDK kompilacji źródłowej

Zestaw SDK oparty na dystrybucji systemu Linux (kompilacja źródłowa) ma teraz możliwość tworzenia samodzielnych aplikacji przy użyciu pakietów środowiska uruchomieniowego source-build. Pakiet środowiska uruchomieniowego specyficznego dla dystrybucji jest powiązany z zestawem SDK kompilacji źródłowej. Podczas samodzielnego wdrażania ten pakiet środowiska uruchomieniowego w pakiecie będzie się odwoływać, włączając w ten sposób funkcję dla użytkowników.

Natywna obsługa funkcji AOT

Opcja publikowania jako natywna funkcja AOT została po raz pierwszy wprowadzona na platformie .NET 7. Publikowanie aplikacji przy użyciu natywnej funkcji AOT tworzy w pełni samodzielną wersję aplikacji, która nie wymaga środowiska uruchomieniowego — wszystko jest zawarte w jednym pliku. Platforma .NET 8 oferuje następujące ulepszenia publikowania natywnego AOT:

• Dodaje obsługę architektur x64 i Arm64 w systemie macOS.

• Zmniejsza rozmiary natywnych aplikacji AOT w systemie Linux o maksymalnie 50%. W poniższej tabeli przedstawiono rozmiar aplikacji "Hello World" opublikowanej za pomocą natywnej funkcji AOT, która obejmuje całe środowisko uruchomieniowe platformy .NET na platformie .NET 7 a .NET 8:

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

• Umożliwia określenie preferencji optymalizacji: rozmiaru lub szybkości. Domyślnie kompilator wybiera generowanie szybkiego kodu przy jednoczesnym zważeniu na rozmiar aplikacji. Można jednak użyć <OptimizationPreference> właściwości MSBuild, aby zoptymalizować specjalnie dla jednego lub drugiego. Aby uzyskać więcej informacji, zobacz Optymalizowanie wdrożeń AOT.

Szablon aplikacji konsolowej

Domyślny szablon aplikacji konsolowej zawiera teraz obsługę gotowego rozwiązania AOT. Aby utworzyć projekt skonfigurowany do kompilacji AOT, wystarczy uruchomić polecenie dotnet new console --aot. Konfiguracja projektu dodana przez --aot program ma trzy efekty:

• Generuje natywny plik wykonywalny z natywną funkcją AOT podczas publikowania projektu, na przykład za pomocą dotnet publish programu Lub programu Visual Studio.
• Umożliwia analizatory zgodności do przycinania, AOT i pojedynczego pliku. Te analizatory ostrzegają cię o potencjalnie problematycznych częściach projektu (jeśli istnieją).
• Umożliwia emulację czasu debugowania AOT, aby podczas debugowania projektu bez kompilacji AOT uzyskać podobne środowisko do AOT. Jeśli na przykład użyto System.Reflection.Emit w pakiecie NuGet, który nie został oznaczony adnotacją dla usługi AOT (i dlatego został pominięty przez analizator zgodności), emulacja oznacza, że nie będziesz mieć żadnych niespodzianek podczas próby opublikowania projektu za pomocą usługi AOT.

Określanie docelowych platform podobnych do systemu iOS za pomocą natywnej funkcji AOT

Platforma .NET 8 uruchamia pracę w celu włączenia natywnej obsługi AOT dla platform podobnych do systemu iOS. Teraz można kompilować i uruchamiać aplikacje .NET iOS i .NET MAUI z natywną funkcją AOT na następujących platformach:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Wstępne testowanie pokazuje, że rozmiar aplikacji na dysku zmniejsza się o około 35% w przypadku aplikacji platformy .NET dla systemu iOS korzystających z natywnej AOT zamiast mono. Rozmiar aplikacji na dysku dla aplikacji .NET MAUI dla systemu iOS zmniejsza się do 50%. Ponadto czas uruchamiania jest również krótszy. Aplikacje platformy .NET dla systemu iOS mają około 28% krótszy czas uruchamiania, a aplikacje .NET MAUI dla systemu iOS mają około 50% lepszej wydajności uruchamiania w porównaniu z aplikacją Mono. Obsługa platformy .NET 8 jest eksperymentalna i tylko pierwszym krokiem dla funkcji jako całości. Aby uzyskać więcej informacji, zobacz wpis w blogu .NET 8 Performance Improvements in .NET MAUI (Ulepszenia wydajności platformy .NET 8 na platformie .NET MAUI).

Natywna obsługa funkcji AOT jest dostępna jako funkcja zgody przeznaczona do wdrożenia aplikacji; Mono jest nadal domyślnym środowiskiem uruchomieniowym na potrzeby tworzenia i wdrażania aplikacji. Aby skompilować i uruchomić aplikację .NET MAUI z natywną funkcją AOT na urządzeniu z systemem iOS, użyj polecenia dotnet workload install maui , aby zainstalować obciążenie .NET MAUI i dotnet new maui -n HelloMaui utworzyć aplikację. Następnie ustaw właściwość PublishAot MSBuild na true w pliku projektu.

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

Po ustawieniu wymaganej właściwości i uruchomieniu dotnet publish , jak pokazano w poniższym przykładzie, aplikacja zostanie wdrożona przy użyciu natywnej funkcji AOT.

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

Ograniczenia

Nie wszystkie funkcje systemu iOS są zgodne z natywną funkcją AOT. Podobnie nie wszystkie biblioteki powszechnie używane w systemie iOS są zgodne z funkcją NativeAOT. Oprócz istniejących ograniczeń wdrożenia natywnego AOT na poniższej liście przedstawiono niektóre inne ograniczenia dotyczące platform podobnych do systemu iOS:

• Używanie natywnej funkcji AOT jest włączone tylko podczas wdrażania aplikacji (dotnet publish).
• Debugowanie kodu zarządzanego jest obsługiwane tylko w przypadku platformy Mono.
• Zgodność z platformą .NET MAUI jest ograniczona.

Kompilacja AOT dla aplikacji systemu Android

Aby zmniejszyć rozmiar aplikacji, aplikacje .NET i .NET MAUI przeznaczone dla systemu Android używają trybu kompilacji przed czasem (AOT), gdy są one wbudowane w tryb wydania. Profilowana kompilacja AOT ma wpływ na mniej metod niż zwykła kompilacja AOT. Platforma .NET 8 wprowadza <AndroidStripILAfterAOT> właściwość umożliwiającą dalsze kompilowanie AOT dla aplikacji systemu Android w celu jeszcze większego zmniejszenia rozmiaru aplikacji.

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

Domyślnie ustawienie AndroidStripILAfterAOTtrue powoduje przesłonięcia ustawienia domyślnego AndroidEnableProfiledAot , zezwalając (prawie) na przycinanie wszystkich metod skompilowanych przez AOT. Możesz również użyć profilowanego usuwania AOT i IL, jawnie ustawiając obie właściwości na true:

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

Międzykompilowane aplikacje systemu Windows

Podczas tworzenia aplikacji przeznaczonych dla systemu Windows na platformach innych niż Windows wynikowy plik wykonywalny jest teraz aktualizowany przy użyciu dowolnych określonych zasobów Win32 — na przykład ikony aplikacji, manifestu, informacji o wersji.

Wcześniej aplikacje musiały być tworzone w systemie Windows, aby mieć takie zasoby. Naprawienie tej luki w obsłudze obejmującej wiele budynków było popularnym żądaniem, ponieważ był to znaczący punkt bólu wpływający zarówno na złożoność infrastruktury, jak i użycie zasobów.

Platforma .NET w systemie Linux

Minimalna pomoc techniczna dla systemu Linux

Minimalne plany bazowe obsługi dla systemu Linux zostały zaktualizowane dla platformy .NET 8. Platforma .NET jest przeznaczona dla systemu Ubuntu 16.04 dla wszystkich architektur. Jest to przede wszystkim ważne w przypadku definiowania minimalnej glibc wersji dla platformy .NET 8. Uruchomienie platformy .NET 8 nie powiedzie się w wersjach dystrybucji, które obejmują starszy glibc, taki jak Ubuntu 14.04 lub Red Hat Enterprise Linux 7.

Aby uzyskać więcej informacji, zobacz Red Hat Enterprise Linux Family support (Obsługa rodziny systemu Linux w systemie Red Hat Enterprise).

Tworzenie własnej platformy .NET w systemie Linux

W poprzednich wersjach platformy .NET można było skompilować platformę .NET ze źródła, ale wymagane było utworzenie "źródłowego tarballa" z repozytorium dotnet/installer , które odpowiada wydaniu. Na platformie .NET 8 nie jest to już konieczne i możesz skompilować platformę .NET w systemie Linux bezpośrednio z repozytorium dotnet/dotnet . To repozytorium używa narzędzia dotnet/source-build do tworzenia środowisk uruchomieniowych, narzędzi i zestawów SDK platformy .NET. Jest to ta sama kompilacja, która jest używana przez oprogramowanie Red Hat i Canonical do kompilowania platformy .NET.

Kompilowanie w kontenerze jest najprostszym rozwiązaniem dla większości osób, ponieważ dotnet-buildtools/prereqs obrazy kontenerów zawierają wszystkie wymagane zależności. Aby uzyskać więcej informacji, zobacz instrukcje dotyczące kompilacji.

Weryfikacja podpisu Narzędzia NuGet

Począwszy od platformy .NET 8, narzędzie NuGet domyślnie weryfikuje podpisane pakiety w systemie Linux. Narzędzie NuGet nadal weryfikuje podpisane pakiety w systemie Windows.

Większość użytkowników nie powinna zauważyć weryfikacji. Jeśli jednak masz istniejący pakiet certyfikatu głównego znajdujący się w lokalizacji /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, mogą pojawić się błędy zaufania, którym towarzyszy ostrzeżenie NU3042.

Możesz zrezygnować z weryfikacji, ustawiając zmienną środowiskową DOTNET_NUGET_SIGNATURE_VERIFICATION na false.

Analiza kodu

Platforma .NET 8 zawiera kilka nowych analizatorów kodu i poprawek, które ułatwiają sprawdzenie, czy prawidłowo i wydajnie używasz interfejsów API biblioteki platformy .NET. Poniższa tabela zawiera podsumowanie nowych analizatorów.

Identyfikator zasady	Kategoria	opis
CA1856	Wydajność	Uruchamia się, gdy ConstantExpectedAttribute atrybut nie jest poprawnie stosowany w parametrze.
CA1857	Wydajność	Uruchamia się, gdy parametr jest oznaczony adnotacją, ConstantExpectedAttribute ale podany argument nie jest stałą.
CA1858	Wydajność	Aby określić, czy ciąg zaczyna się od danego prefiksu, lepiej wywołać metodę niż wywołać String.StartsWithString.IndexOf , a następnie porównać wynik z zerem.
CA1859	Wydajność	Ta reguła zaleca uaktualnienie typu określonych zmiennych lokalnych, pól, właściwości, parametrów metody i typów zwracanych metody z interfejsu lub typów abstrakcyjnych do konkretnych typów, jeśli to możliwe. Użycie konkretnych typów prowadzi do generowania kodu o wyższej jakości.
CA1860	Wydajność	Aby określić, czy typ kolekcji ma jakiekolwiek elementy, lepiej użyć Lengthmetody , Countlub IsEmpty niż wywołać metodę Enumerable.Any.
CA1861	Wydajność	Tablice stałe przekazywane jako argumenty nie są ponownie używane podczas wywoływanego wielokrotnie, co oznacza, że nowa tablica jest tworzona za każdym razem. Aby zwiększyć wydajność, rozważ wyodrębnienie tablicy do statycznego pola tylko do odczytu.
CA1865-CA1867	Wydajność	Przeciążenie znaków jest lepszym przeciążeniem dla ciągu z pojedynczym znakiem.
CA2021	Niezawodność	Enumerable.Cast<TResult>(IEnumerable) i Enumerable.OfType<TResult>(IEnumerable) wymagają, aby zgodne typy działały poprawnie. Konwersje rozszerzające i konwersje zdefiniowane przez użytkownika nie są obsługiwane w przypadku typów ogólnych.
CA1510-CA1513	Możliwość konserwacji	Pomocnicy zgłaszania są prostsze i wydajniejsze niż if blok tworzący nowe wystąpienie wyjątku. Te cztery analizatory zostały utworzone dla następujących wyjątków: ArgumentNullException, ArgumentExceptionArgumentOutOfRangeException i ObjectDisposedException.

Diagnostyka

Przeładowywanie na gorąco języka C# obsługuje modyfikowanie typów ogólnych

Począwszy od platformy .NET 8, Przeładowywanie na gorąco języka C# obsługuje modyfikowanie typów ogólnych i metod ogólnych. Podczas debugowania aplikacji konsolowych, klasycznych, mobilnych lub WebAssembly za pomocą programu Visual Studio można zastosować zmiany do klas ogólnych i metod ogólnych w kodzie języka C# lub na stronach Razor. Aby uzyskać więcej informacji, zobacz pełną listę edycji obsługiwanych przez roslyn.

Zobacz też

• Co nowego na platformie .NET 8