SDK'daki yenilikler ve .NET 9 araçları

Bu makalede .NET SDK'sının yeni özellikleri ve .NET 9 araçları açıklanmaktadır.

Birim testi

Bu bölümde, .NET 9'da birim testi güncelleştirmeleri açıklanmaktadır: testleri paralel olarak çalıştırma ve Terminal Günlük Kaydedici testi çıkışı.

Testleri paralel çalıştırma

.NET 9'da, dotnet test MSBuild ile tamamen tümleşiktir. MSBuild paralel derlemeyi desteklediğinden, aynı proje için testleri farklı hedef çerçevelerde paralel olarak çalıştırabilirsiniz. Varsayılan olarak, MSBuild paralel işlemlerin sayısını bilgisayardaki işlemci sayısıyla sınırlar. -maxcpucount anahtarını kullanarak da kendi sınırınızı ayarlayabilirsiniz. Paralelliği geri çevirmek istiyorsanız, TestTfmsInParallel MSBuild özelliğini falseolarak ayarlayın.

Terminal Günlükçü test ekranı

için dotnet test test sonucu raporlaması artık doğrudan MSBuild Terminal Günlükçüsü'nde desteklenmektedir. testler çalışırken (çalışan testin adı gösterilir) ve testler tamamlandıktan sonra (herhangi bir test hatası daha iyi bir şekilde gösterilir) daha tam özellikli test raporlaması elde edersiniz.

Terminal Kaydedici hakkında daha fazla bilgi için bkz. dotnet derleme seçenekleri.

.NET aracı ileri güncelleme

.NET araçları , genel olarak veya yerel olarak yükleyebileceğiniz, ardından .NET SDK'sını ve yüklü .NET çalışma zamanlarını kullanarak çalıştırabileceğiniz çerçeveye bağımlı uygulamalardır. Tüm .NET uygulamaları gibi bu araçlar da .NET'in belirli bir ana sürümünü hedefler. Varsayılan olarak, uygulamalar .NET'in daha yeni sürümlerinde çalışmaz. Araç yazarları, RollForward MSBuild özelliğini ayarlayarak araçlarını .NET çalışma zamanının daha yeni sürümlerinde çalıştırmayı tercih edebildi. Ancak, tüm araçlar bunu yapmaz.

dotnet tool install için yeni bir seçenek, kullanıcıların .NET araçlarının nasıl çalıştırılacağına karar olanak tanır. dotnet tool installaracılığıyla bir araç yüklediğinizde veya aracı dotnet tool run <toolname>aracılığıyla çalıştırdığınızda, --allow-roll-forwardadlı yeni bir bayrak belirtebilirsiniz. Bu seçenek, aracı Majorileri sarma moduyla yapılandırır. Bu mod, eşleşen .NET sürümü kullanılamıyorsa aracın .NET'in daha yeni bir ana sürümünde çalışmasına olanak tanır. Bu özellik, araç yazarlarının herhangi bir kodu değiştirmek zorunda kalmadan erken benimseyenlerin .NET araçlarını kullanmasına yardımcı olur.

Terminal Kaydedici

Terminal Günlükçü artık varsayılan olarak etkindir ve kullanılabilirliği de geliştirmiştir.

Varsayılan olarak etkin

.NET 9'dan başlayarak, MSBuild kullanan tüm .NET CLI komutları için varsayılan deneyim, .NET 8'de yayımlanan gelişmiş günlük deneyimi olan Terminal Logger'dır. Bu yeni çıkış, aşağıdaki gibi işlevler sağlamak için modern terminallerin özelliklerini kullanır:

• Tıklanabilir bağlantılar
• MSBuild görevleri için süre süreölçerleri
• Uyarı ve hata iletilerinin renk kodlaması

Çıktı, mevcut MSBuild konsol günlükçüsüne göre daha sade ve kullanışlı.

Yeni günlükçü, kullanılıp kullanılamayacağını otomatik olarak algılamaya çalışır, ancak Terminal Günlükçü'lerinin kullanılıp kullanılmadığını el ile denetleyebilirsiniz. --tl:off Terminal Kaydedici'yi belirtilen bir komut için devre dışı bırakmak amacıyla komut satırı seçeneğini belirtin. Veya Terminal Günlükçü'lerini daha geniş bir şekilde devre dışı bırakmak için ortam değişkenini MSBUILDTERMINALLOGGER olarak offayarlayın.

Varsayılan olarak Terminal Günlükçüsünün kullanıldığı komut kümesi:

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

Kullanılabilir -lik

Terminal Kayıt Tutucu artık derleme sonunda toplam hata ve uyarı sayısını özetler. Ayrıca yeni satırlar içeren hataları da gösterir. (Bu Terminal Günlükçüsü hakkında daha fazla bilgi almak için, 'dotnet build' seçeneklerine, özellikle --tl seçeneğine bakınız.)

Proje oluşturulduğunda uyarı veren aşağıdaki proje dosyasını göz önünde bulundurun:

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

.NET 8 SDK'sında dotnet build -tl çalıştırdığınızda, çıktı bu paragrafın ardından gösterildiği gibi görünür. Çok satırlı uyarının her satırı, çıktıda tam hata iletisi ön ekine sahip ayrı bir satırdır ve bu da okunmasını zorlaştırır. Ayrıca, son derleme özetinde uyarı olduğu ancak kaç olmadığı belirtiliyor. Eksik bilgiler, belirli bir derlemenin önceki derlemelerden daha iyi mi yoksa daha mı kötü olduğunu saptamayı zorlaştırabilir.

$ 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

.NET 9 SDK'sını kullanarak aynı projeyi oluşturduğunuzda çıkış aşağıdaki gibidir:

> 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

Uyarının ileti satırlarında artık ekranı karmaşık hale getiren yinelenen proje ve konum bilgileri yoktur. Ayrıca derleme özeti, derleme sırasında kaç uyarının (ve varsa hataların) oluşturulduğunu gösterir.

Terminal Günlükçü hakkında geri bildiriminiz varsa, bunu MSBuild deposunda sağlayabilirsiniz.

Büyük depolar için daha hızlı NuGet bağımlılık çözümlemesi

Tüm <PackageReference> projelerinin performansını ve ölçeklenebilirliğini artırmak için NuGet bağımlılık çözümleyicisi elden geçirildi. Varsayılan olarak etkin olan yeni algoritma, işlevsellikten ödün vermeden geri yükleme işlemlerini hızlandırır ve kesinlikle temel bağımlılık çözümleme kurallarına uyar.

Geri yükleme hataları veya beklenmeyen paket sürümleri gibi sorunlarla karşılaşırsanız, eski çözümleyiciye geri dönebilirsiniz.

MSBuild betik çözümleyicileri ("BuildChecks")

.NET 9, derleme betiklerinizdeki hatalara ve regresyonlara karşı korumaya yardımcı olan bir özellik sağlar. Derleme denetimlerini çalıştırmak için, MSBuild'i çağıran herhangi bir komuta /check bayrağını ekleyin. Örneğin, dotnet build myapp.sln /checkmyapp çözümünü oluşturur ve yapılandırılmış tüm derleme denetimlerini çalıştırır.

.NET 9 SDK'sı, BC0101 ve BC0102gibi az sayıda ilk denetim içerir. Tam liste için bkz. BuildCheck kodları.

Bir sorun algılandığında, sorunu içeren projenin derleme çıkışında bir tanılama oluşturulur.

Daha fazla bilgi için tasarım belgelerine bakın.

Çözümleyici uyuşmazlığı

Birçok kullanıcı .NET SDK'sını ve Visual Studio'yu farklı tempolarda yükler. Bu esneklik istense de, iki ortam arasında birlikte çalışma ihtiyacı olan araçlarda sorunlara yol açabilir. Bu tür araçlardan biri Roslyn Çözümleyicileri'dir. Çözümleyici yazarlarının Roslyn'in belirli sürümleri için kod oluşturmaları gerekir, ancak hangi sürümlerin kullanılabildiği ve belirli bir derleme tarafından kullanılanlar bazen belirsizdir.

.NET SDK ile MSBuild arasındaki bu tür sürüm uyuşmazlığı, bozuk SDKolarak adlandırılır. Bu durumdayken aşağıdaki gibi hatalar görebilirsiniz:

CSC : uyarı CS9057: Çözümleyici derlemesi '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll' şu anda çalışan '4.8.0.0' sürümünden daha yeni olan derleyicinin '4.9.0.0' sürümüne başvurur.

.NET 9, bu sorun senaryolarını algılayabilir ve otomatik olarak ayarlayabilir. SDK'nın MSBuild mantığı, birlikte gönderilen MSBuild sürümünü ekler ve bu bilgiler SDK'nın farklı bir sürüme sahip bir ortamda ne zaman çalıştığını algılamak için kullanılabilir. Bu durumda SDK, tutarlı bir çözümleyici deneyimi sağlayan Microsoft.Net.Sdk.Compilers.Toolset adlı destek paketinin örtük bir indirmesini ekler.

İş yükü kümeleri

İş yükü kümeleri, kullanıcılara yükledikleri iş yükleri ve bu iş yüklerinin değişim temposu üzerinde daha fazla denetim sağlamayı amaçlayan bir SDK özelliğidir. Önceki sürümlerde, tek tek iş yüklerinin yeni sürümleri yapılandırılmış NuGet akışlarına yayımlandıkları için iş yükleri düzenli aralıklarla güncelleştirildi. Şimdi iş yüklerinizin tüm siz açık bir güncelleştirme hareketi yapıncaya kadar belirli, tek bir sürümde kalır.

dotnet workload --infoçalıştırarak SDK yüklemenizin hangi modda olduğunu görebilirsiniz:

> 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

Bu örnekte SDK yüklemesi , güncelleştirmelerin kullanılabilir olduğu şekilde yüklendiği 'bildirim' modundadır. Yeni moda geçmek için bir --version veya dotnet workload install komutuna dotnet workload update seçeneği ekleyin. Ayrıca yeni dotnet workload config komutunu kullanarak işlem modunuzu açıkça denetleyebilirsiniz:

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

Herhangi bir nedenle geri değiştirmeniz gerekirse, aynı komutu manifestsyerine workload-set ile çalıştırabilirsiniz. Geçerli işlem modunu denetlemek için dotnet workload config --update-mode de kullanabilirsiniz.

Daha fazla bilgi için bkz. .NET SDK iş yükü kümeleri .

İş yükü geçmişi

.NET SDK iş yükleri .NET MAUI ve Blazor WebAssembly'nin ayrılmaz bir parçasıdır. Varsayılan yapılandırmalarında, .NET araç yazarları yeni sürümler yayımladıkça iş yüklerini bağımsız olarak güncelleştirebilirsiniz. Ayrıca, Visual Studio aracılığıyla yapılan .NET SDK yüklemeleri paralel bir sürüm kümesi yükler. Dikkat edilmeden, belirli bir .NET SDK yüklemesinin iş yükü yükleme durumu zaman içinde kayabilir, ancak bu kaymayı görselleştirmenin bir yolu yoktur.

Bunu gidermek için .NET 9, .NET SDK'sına yeni bir dotnet workload history komutu ekler. dotnet workload history, geçerli .NET SDK yüklemesi için iş yükü kurulumları ve değişikliklerinin geçmişine ait bir tabloyu yazdırır. Tabloda yükleme veya değişikliğin tarihi, çalıştırılan komut, yüklenen veya değiştirilen iş yükleri ve komutun ilgili sürümleri gösterilir. Bu çıkış, zaman içinde iş yükü yüklemelerindeki kaymayı anlamanıza ve yüklemenizi ayarlayabileceğiniz iş yükleri sürümleri hakkında bilinçli kararlar vermenize yardımcı olabilir. Bunu iş yükleri için git reflog olarak düşünebilirsiniz.

> 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

Bu örnekte SDK başlangıçta android, ios, maccatalystve maui-windows iş yükleriyle birlikte yüklenmiştir. Ardından dotnet workload install aspire --version 9.0.100-rc.1.24453.3 iş yükünü yüklemek ve aspireiş yükü kümeleri moduna geçmek için komutu kullanıldı. Önceki duruma dönmek için geçmiş tablosundaki ilk sütundaki kimliği kullanabilirsiniz, örneğin, dotnet workload update --from-history 1.

Konteyner

• Güvenli olmayan kayıt defterleri için yayımlama desteği
• Ortam değişkeni adlandırma

Güvenli olmayan kayıt defterleri için yayımlama desteği

SDK'nın yerleşik kapsayıcı yayımlama desteği, kapsayıcı kayıt defterlerine görüntü yayımlayabilir. .NET 9'a kadar bu kayıt defterlerinin güvenliğinin sağlanması gerekiyordu; .NET SDK'sının çalışması için HTTPS desteğine ve geçerli sertifikalara ihtiyaçları vardı. Kapsayıcı altyapıları genellikle güvenli olmayan kayıt defterleriyle, yani TLS yapılandırılmamış veya TLS'nin geçersiz bir sertifikayla yapılandırılmış olduğu kayıt defterleriyle çalışacak şekilde yapılandırılabilir. Bu geçerli bir kullanım örneğidir, ancak araçlarımız bu iletişim modunu desteklemedi.

.NET 9'dan başlayarak SDK, güvenli olmayan kayıt defterleriyle iletişim kurabilir.

Gereksinimler (ortamınıza bağlı olarak):

• Docker CLI'yi bir kayıt defterini güvenli değil olarak işaretleye yapılandırın.
• Podman'ı bir kayıt defterini güvenli değil olarak işaretlemek için yapılandırın.
• DOTNET_CONTAINER_INSECURE_REGISTRIES ortam değişkenini kullanarak güvenli olmayan olarak davranacak, noktalı virgülle ayrılmış kayıt defteri etki alanlarının listesini geçirin.

Ortam değişkeni adlandırma

Kapsayıcı yayımlama araçlarının kayıt defteri iletişiminin ve güvenliğin daha ince yönlerinden bazılarını denetlemek için kullandığı ortam değişkenleri artık DOTNETyerine ön ek SDK ile başlar. SDK ön eki yakın dönemde desteklenmeye devam edecektir.

Kod analizi

.NET 9, .NET kitaplık API'lerini doğru ve verimli bir şekilde kullandığınızı doğrulamaya yardımcı olmak için birkaç yeni kod çözümleyicisi ve düzeltici içerir. Aşağıdaki tablo yeni çözümleyicileri özetlemektedir.

Kural Kimliği	Kategori	Açıklama
CA1514 : Gereksiz uzunluk bağımsız değişkeninden kaçının	Bakım Kolaylığı	Uzunluğu açıkça hesaplanmış bir bağımsız değişken hataya açıktır ve bir dizenin veya arabelleğin sonuna kesme yaparken gereksizdir.
CA1515 : Genel türleri dahili yapmayı göz önünde bulundurun	Bakım Kolaylığı	Yürütülebilir derleme içindeki türler internalolarak bildirilmelidir.
CA1871: 'ArgumentNullException.ThrowIfNull' işlemine null atanabilir bir yapıyı geçirmeyin	Performans	Geliştirilmiş performans için, HasValue özelliğini denetlemek ve hata fırlatmak, ArgumentNullException.ThrowIfNull'e null atanabilir bir yapı geçirmekten daha iyidir.
CA1872: 'BitConverter.ToString' dayalı çağrı zincirleri yerine 'Convert.ToHexString' ve 'Convert.ToHexStringLower' tercih edin	Performans	Baytları onaltılık dize gösterimine kodlarken Convert.ToHexString veya Convert.ToHexStringLower kullanın.
CA2022: Stream.Read ile uygun olmayan okuma yapmaktan kaçının.	Güvenilirlik	Stream.Read çağrısı istenenden daha az bayt döndürebilir ve sonuç olarak dönüş değeri işaretlenmemişse güvenilir olmayan kod elde edilir.
CA2262: 'MaxResponseHeadersLength' ayarını uygun şekilde yapın	Kullanım	HttpClientHandler.MaxResponseHeadersLength özelliği bayt değil kilobayt cinsinden ölçülür.
CA2263: Tür bilindiğinde genel aşırı yüklemeyi tercih edin	Kullanım	Derleme zamanında tür bilindiğinde, System.Type türündeki bir bağımsız değişkeni kabul eden aşırı yüklemelerdense genel aşırı yüklemeler tercih edilir.
CA2264: 'ArgumentNullException.ThrowIfNull' null atanamaz bir değer geçirmeyin	Kullanım	Null atanamayan yapılar (Nullable<T>hariç), 'nameof()' ifadeleri ve 'new' ifadeleri gibi bazı yapıların hiçbir zaman null olmayacağı bilinir; bu yüzden ArgumentNullException.ThrowIfNull asla bir hata fırlatmaz.
CA2265: Span<T> null veya varsayılan ile karşılaştırmayın	Kullanım	Bir aralığı null veya default ile karşılaştırmak, istediğiniz sonucu sağlamayabilir. default ve null literal ifadeleri örtük olarak Span<T>.Empty'ye dönüştürülür. yedekli karşılaştırmayı kaldırın veya IsEmptykullanarak kodu daha açık hale getirin.