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

W tym artykule opisano nowe funkcje zestawu .NET SDK i narzędzi dla platformy .NET 9.

Testowanie jednostkowe

W tej sekcji opisano aktualizacje testów jednostkowych na platformie .NET 9: równoległe uruchamianie testów oraz dane wyjściowe testu rejestratora terminalu.

Równoległe uruchamianie testów

Na platformie .NET 9 dotnet test jest w pełni zintegrowana z programem MSBuild. Ponieważ program MSBuild obsługuje równoległe tworzenie , można uruchamiać testy dla tego samego projektu w różnych platformach docelowych równolegle. Domyślnie program MSBuild ogranicza liczbę procesów równoległych do liczby procesorów na komputerze. Możesz również ustawić własny limit przy użyciu przełącznika -maxcpucount. Jeśli chcesz zrezygnować z przetwarzania równoległego, ustaw właściwość TestTfmsInParallel MSBuild na false.

Wyświetlanie testu rejestratora terminalu

Raportowanie wyników testów dla programu dotnet test jest teraz obsługiwane bezpośrednio w rejestratorze terminalu programu MSBuild. Uzyskasz bardziej funkcjonalne raportowanie testów podczas uruchamiania testów (wyświetla działającą nazwę testu) i po zakończeniu testów (wszelkie błędy testowe są renderowane w lepszy sposób).

Aby uzyskać więcej informacji na temat rejestratora terminali, zobacz dotnet build options (Opcje kompilacji dotnet).

Roll-forward narzędzia .NET

narzędzia .NET to aplikacje zależne od platformy, które można instalować globalnie lub lokalnie, a następnie uruchamiać przy użyciu zestawu .NET SDK i zainstalowanych środowisk uruchomieniowych platformy .NET. Te narzędzia, takie jak wszystkie aplikacje platformy .NET, dotyczą określonej wersji głównej platformy .NET. Domyślnie aplikacje nie są uruchamiane na nowszych wersjach platformy .NET. Autorzy narzędzi mogli wyrazić zgodę na uruchamianie swoich narzędzi w nowszych wersjach środowiska uruchomieniowego platformy .NET przez ustawienie właściwości RollForward MSBuild. Jednak nie wszystkie narzędzia to robią.

Nowa opcja dotnet tool install umożliwia użytkownikom decydowanie o tym, jak powinny być uruchamiane narzędzia platformy .NET. Podczas instalowania narzędzia za pomocą dotnet tool installlub podczas uruchamiania narzędzia za pośrednictwem dotnet tool run <toolname>można określić nową flagę o nazwie --allow-roll-forward. Ta opcja umożliwia skonfigurowanie narzędzia w trybie przesuwania naprzód Major. Ten tryb umożliwia uruchamianie narzędzia w nowszej wersji głównej platformy .NET, jeśli zgodna wersja platformy .NET jest niedostępna. Ta funkcja pomaga wczesnym adoptatorom używać narzędzi platformy .NET bez konieczności zmiany kodu przez autorów narzędzi.

Rejestrator terminalu

Rejestrator terminalu jest teraz domyślnie włączony , a także ma lepszą użyteczność.

Domyślnie włączone

Począwszy od platformy .NET 9, domyślne środowisko dla wszystkich poleceń interfejsu wiersza polecenia platformy .NET używających programu MSBuild to Rejestrator terminalu, ulepszone środowisko rejestrowania wydane na platformie .NET 8. Te nowe dane wyjściowe korzystają z możliwości nowoczesnych terminali w celu zapewnienia takich funkcji jak:

• Linki z możliwością klikania
• Czasomierze czasu trwania dla zadań PROGRAMU MSBuild
• Kodowanie kolorami komunikatów ostrzegawczych i komunikatów o błędach

Dane wyjściowe są bardziej skondensowane i użyteczne niż istniejący rejestrator konsoli MSBuild.

Nowy rejestrator próbuje automatycznie wykryć, czy można go użyć, ale można również ręcznie kontrolować, czy jest używany rejestrator terminalu. Określ opcję wiersza polecenia --tl:off, aby wyłączyć rejestrator terminalu dla określonego polecenia. Możesz też wyłączyć rejestrator terminalu w szerszym zakresie, ustawiając zmienną środowiskową MSBUILDTERMINALLOGGER na wartość off.

Zestaw poleceń, które domyślnie używają rejestratora terminali, to:

• build
• clean
• msbuild
• pack
• publish
• restore
• test

Użyteczność

Rejestrator terminalu podsumowuje teraz łączną liczbę błędów i ostrzeżeń na końcu kompilacji. Pokazuje również błędy zawierające nowe wiersze. (Aby uzyskać więcej informacji na temat rejestratora terminali, zobacz opcje "Dotnet build", w szczególności opcję --tl.)

Rozważ następujący plik projektu, który generuje ostrzeżenie podczas budowania projektu.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <Target Name="Error" BeforeTargets="Build">
    <Warning Code="ECLIPSE001" Text="Black Hole Sun, won't you come
  And wash away the rain
    Black Hole Sun, won't you come
      won't you come" />
  </Target>
</Project>

Po uruchomieniu dotnet build -tl na zestawie SDK platformy .NET 8 dane wyjściowe są pokazane poniżej tego akapitu. Każdy wiersz ostrzeżenia wielowierszowego jest osobnym wierszem z pełnym prefiksem komunikatu o błędzie w danych wyjściowych, co jest trudne do odczytania. Ponadto końcowe podsumowanie kompilacji zwraca uwagę, że były ostrzeżenia, ale nie precyzuje , ile dokładnie ich było. Brakujące informacje mogą utrudnić ustalenie, czy określona kompilacja jest lepsza lub gorsza niż poprzednie kompilacje.

$ dotnet build -tl
MSBuild version 17.8.5+b5265ef37 for .NET
Restore complete (0.5s)
  multiline-error-example succeeded with warnings (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001: Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:   And wash away the rain
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:     Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:       won't you come
Build succeeded with warnings in 0.9s

Podczas kompilowanie tego samego projektu przy użyciu zestawu .NET 9 SDK dane wyjściowe są następujące:

> dotnet build -tl
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  multiline-error-example succeeded with 3 warning(s) (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:
      Black Hole Sun, won't you come
        And wash away the rain
          Black Hole Sun, won't you come
            won't you come
Build succeeded with 3 warning(s) in 0.8s

Wiersze komunikatu ostrzeżenia nie zawierają już powtarzających się informacji o projekcie i lokalizacji, które zaśmiecają ekran. Ponadto podsumowanie kompilacji pokazuje liczbę ostrzeżeń (i błędów, jeśli istnieją) wygenerowanych podczas kompilacji.

Jeśli masz opinię na temat rejestratora terminali, możesz przekazać go w repozytorium MSBuild.

Szybsze rozwiązywanie zależności narzędzia NuGet dla dużych repozytoriów

Narzędzie rozpoznawania zależności NuGet zostało poprawione w celu zwiększenia wydajności i skalowalności dla wszystkich projektów <PackageReference>. Domyślnie nowy algorytm przyspiesza operacje przywracania bez naruszania funkcjonalności, ściśle przestrzegając podstawowych reguł rozwiązywania zależności.

Jeśli wystąpią jakiekolwiek problemy, takie jak niepowodzenia przywracania lub nieoczekiwane wersje pakietów, możesz powrócić do starszego rozwiązania.

Analizatory skryptów MSBuild ("BuildChecks")

Platforma .NET 9 wprowadza funkcję, która pomaga chronić przed wadami i regresjami w skryptach kompilacji. Aby uruchomić kontrole kompilacji, dodaj flagę /check do dowolnego polecenia, które wywołuje program MSBuild. Na przykład dotnet build myapp.sln /check kompiluje rozwiązanie myapp i uruchamia wszystkie skonfigurowane testy kompilacji.

Zestaw .NET 9 SDK zawiera niewielką liczbę testów początkowych, na przykład BC0101 i BC0102. Aby uzyskać pełną listę, zobacz BuildCheck codes.

Po wykryciu problemu w danych wyjściowych kompilacji zostanie utworzona diagnostyka projektu zawierającego problem.

Aby uzyskać więcej informacji, zobacz dokumentację projektowania .

Niezgodność analizatora

Wielu użytkowników instaluje zestaw .NET SDK i program Visual Studio w różnych cyklach. Chociaż ta elastyczność jest pożądana, może to prowadzić do problemów z narzędziami, które muszą współdziałać między dwoma środowiskami. Jednym z przykładów tego rodzaju narzędzi jest Roslyn Analyzers. Autorzy analizatorów muszą kodować dla określonych wersji programu Roslyn, ale które wersje są dostępne i które są używane przez daną kompilację, czasami nie jest jasne.

Ten rodzaj niezgodności wersji między zestawem SDK platformy .NET i programem MSBuild jest określany jako rozdarty zestaw SDK . Gdy jesteś w tym stanie, mogą pojawić się błędy podobne do poniższych:

CSC : ostrzeżenie CS9057: zestaw analizatora '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll" odwołuje się do wersji "4.9.0.0" kompilatora, która jest nowsza niż obecnie uruchomiona wersja "4.8.0.0".

Platforma .NET 9 może wykrywać i automatycznie dostosowywać się do tego scenariusza problemu. Logika MSBuild zestawu SDK osadza wersję programu MSBuild, z którą jest dostarczana, a te informacje mogą służyć do wykrywania, gdy zestaw SDK działa w środowisku z inną wersją. W takim przypadku zestaw SDK wstawia niejawne pobieranie pakietu pomocy technicznej o nazwie Microsoft.Net.Sdk.Compilers.Toolset, który zapewnia spójne doświadczenie z analizatorem.

Zestawy obciążeń

Zestawy obciążeń to funkcja zestawu SDK, która umożliwia użytkownikom większą kontrolę nad instalowanymi obciążeniami oraz cyklem zmian tych obciążeń. W poprzednich wersjach obciążenia były okresowo aktualizowane w miarę wydawania nowych wersji poszczególnych obciążeń na wszystkie skonfigurowane źródła danych NuGet. Teraz wszystkie obciążenia pozostają w określonej, jednej wersji do momentu wykonania ręcznej aktualizacji.

Możesz sprawdzić, w jakim trybie znajduje się instalacja zestawu SDK, uruchamiając dotnet workload --info:

> dotnet workload --info
Workload version: 9.0.100-manifests.400dd185
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
   Manifest Version:    8.0.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
   Install Type:              Msi

W tym przykładzie instalacja zestawu SDK jest w trybie manifestu, w którym aktualizacje są instalowane w miarę ich dostępności. Aby włączyć nowy tryb, dodaj opcję --version do polecenia dotnet workload install lub dotnet workload update. Możesz również jawnie kontrolować tryb działania przy użyciu nowego polecenia dotnet workload config:

> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.

Jeśli z jakiegoś powodu musisz cofnąć zmiany, możesz uruchomić to samo polecenie, używając manifests zamiast workload-set. Możesz również użyć dotnet workload config --update-mode, aby sprawdzić bieżący tryb działania.

Aby uzyskać więcej informacji, zobacz zestawy robocze platformy .NET SDK .

Historia obciążeń

Obciążenia zestawu .NET SDK są integralną częścią zestawów .NET MAUI i Blazor WebAssembly. W domyślnej konfiguracji można niezależnie aktualizować obciążenia, gdy autorzy narzędzi .NET udostępniają nowe wersje. Ponadto instalacje zestawu .NET SDK wykonywane za pośrednictwem programu Visual Studio instalują równoległy zestaw wersji. Jeśli nie zadbamy o status instalacji obciążeń roboczych dla danej instalacji zestawu .NET SDK, może zmieniać się z czasem, ale nie było dotąd sposobu, aby to zobrazować.

Aby rozwiązać ten problem, platforma .NET 9 dodaje nowe polecenie dotnet workload history do zestawu .NET SDK. dotnet workload history wyświetla tabelę historii instalacji obciążeń i modyfikacji bieżącej instalacji zestawu .NET SDK. W tabeli przedstawiono datę instalacji lub modyfikacji, polecenie, które zostało uruchomione, obciążenia, które zostały zainstalowane lub zmodyfikowane, oraz odpowiednie wersje polecenia. Te dane wyjściowe mogą pomóc zrozumieć dryf w instalacjach obciążeń w czasie i pomóc w podejmowaniu świadomych decyzji dotyczących wersji obciążeń, na które należy ustawić instalację. Można to traktować jako git reflog dla obciążeń.

> dotnet workload history

Id  Date                         Command       Workloads                                        Global.json Version  Workload Version
-----------------------------------------------------------------------------------------------------------------------------------------------
1   1/1/0001 12:00:00 AM +00:00  InitialState  android, ios, maccatalyst, maui-windows                               9.0.100-manifests.6d3c8f5d
2   9/4/2024 8:15:33 PM -05:00   install       android, aspire, ios, maccatalyst, maui-windows                       9.0.100-rc.1.24453.3

W tym przykładzie zestaw SDK został początkowo zainstalowany przy użyciu obciążeń android, ios, maccatalysti maui-windows. Następnie polecenie dotnet workload install aspire --version 9.0.100-rc.1.24453.3 zostało użyte do zainstalowania obciążenia aspire i przełączenia do trybu zestawów obciążeń . Aby powrócić do poprzedniego stanu, możesz użyć identyfikatora z pierwszej kolumny w tabeli historii, na przykład dotnet workload update --from-history 1.

Containers

• obsługa publikowania dla niezabezpieczonych rejestrów
• nazewnictwo zmiennych środowiskowych

Obsługa publikowania dla niezabezpieczonych rejestrów

Wbudowana obsługa publikowania kontenerów zestawu SDK może publikować obrazy w rejestrach kontenerów. Do platformy .NET 9 te rejestry były wymagane do zabezpieczenia — aby zestaw SDK platformy .NET działał, wymagały obsługi protokołu HTTPS i prawidłowych certyfikatów. Silniki kontenerów zwykle można skonfigurować do pracy z niezabezpieczonymi rejestrami, czyli rejestrami, które nie mają skonfigurowanego protokołu TLS lub mają skonfigurowany protokół TLS z nieprawidłowym certyfikatem. Jest to prawidłowy przypadek użycia, ale nasze narzędzia nie obsługiwały tego trybu komunikacji.

Począwszy od platformy .NET 9, zestaw SDK może komunikować się z niezabezpieczonymi rejestrami.

Wymagania (w zależności od środowiska):

• Skonfiguruj interfejs wiersza polecenia platformy Docker, aby oznaczyć rejestr jako niezabezpieczony.
• Skonfiguruj narzędzie Podman, aby oznaczyć rejestr jako niezabezpieczony.
• Użyj zmiennej środowiskowej DOTNET_CONTAINER_INSECURE_REGISTRIES, aby przekazać rozdzieloną średnikami listę domen rejestru w celu traktowania ich jako niezabezpieczonych.

Nazewnictwo zmiennych środowiskowych

Zmienne środowiskowe używane przez narzędzie publikowania kontenera do kontrolowania niektórych bardziej szczegółowych aspektów komunikacji rejestru i zabezpieczeń zaczynają się od prefiksu DOTNET zamiast SDK. Prefiks SDK będzie nadal obsługiwany w najbliższej perspektywie.

Analiza kodu

Platforma .NET 9 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.