SDK'daki yenilikler ve .NET 10 için araçlar

Bu makalede.NET 10 için .NET SDK'sında yeni özellikler ve geliştirmeler açıklanmaktadır.

.NET araçları geliştirmeleri

Platforma özgü .NET araçları

.NET araçları artık tek bir pakette birden çok RuntimeIdentifiers (RID) desteğiyle yayımlanabilir. Araç yazarları desteklenen tüm platformlar için ikili dosyaları paketleyebilir ve .NET CLI yükleme veya çalışma zamanında doğru olanı seçer. Bu, platformlar arası araç yazma ve dağıtmayı çok daha kolay hale getirir.

Bu gelişmiş araçlar çeşitli paketleme çeşitlemelerini destekler:

• Çerçeveye bağımlı, platformdan bağımsız (klasik mod, .NET 10 yüklüyken her yerde çalışır)
• Çerçeveye bağımlı, platforma özgü (daha küçük, her platform için iyileştirilmiş)
• Bağımsız, platforma özgü (çalışma zamanını içerir, .NET yüklemesi gerekmez)
• Kırpılmış, platforma özgü (daha küçük, kullanılmayan kodu kırpıyor)
• AOT ile derlenmiş, platforma özgü (en yüksek performans ve en küçük dağıtım)

Bu yeni araçlar normal yayımlanan uygulamalar gibi çalışır, bu nedenle uygulamalarla kullanabileceğiniz tüm yayımlama seçenekleri (örneğin, bağımsız, kırpılmış veya AOT) araçlara da uygulanabilir.

Tek seferlik araç yürütme

Artık komutunu kullanarak dotnet tool exec bir .NET aracını genel olarak veya yerel olarak yüklemeden yürütebilirsiniz. Bu özellikle CI/CD veya kısa ömürlü kullanım için değerlidir.

dotnet tool exec --source ./artifacts/package/ dotnetsay  "Hello, World!"
Tool package dotnetsay@1.0.0 will be downloaded from source <source>.
Proceed? [y/n] (y): y
  _   _          _   _                __        __                 _       _   _
 | | | |   ___  | | | |   ___         \ \      / /   ___    _ __  | |   __| | | |
 | |_| |  / _ \ | | | |  / _ \         \ \ /\ / /   / _ \  | '__| | |  / _` | | |
 |  _  | |  __/ | | | | | (_) |  _      \ V  V /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

Bu, belirtilen araç paketini tek bir komutta indirir ve çalıştırır. Varsayılan olarak, araç yerel olarak mevcut değilse kullanıcılardan indirmeyi onaylamaları istenir. Seçilen araç paketinin en son sürümü, açık bir sürüm belirtilmediği sürece kullanılır (örneğin, dotnetsay@0.1.0).

Tek seferlik araç yürütme, yerel araç bildirimleriyle sorunsuz çalışır. Yakındaki .config/dotnet-tools.json içeren bir konumdan bir araç çalıştırırsanız, kullanılabilir en son sürüm yerine bu yapılandırmada bulunan sürüm kullanılır.

Yeni dnx aracının komut dosyası

dnx betiği, araçları çalıştırmanın kolay yolunu sağlar. Tüm bağımsız değişkenleri işlenmek üzere CLI'ya dotnet ileterek araç kullanımını mümkün olduğunca basit hale getirir:

dnx dotnetsay "Hello, World!"

Komutun dnx gerçek uygulaması CLI'nın kendisindedir dotnet ve zaman içinde davranışının gelişmesine olanak sağlar.

.NET araçlarını yönetme hakkında daha fazla bilgi için bkz. .NET araçlarını yönetme.

RuntimeIdentifier'i any platforma özgü .NET araçlarıyla kullanma

Platforma özgü .NET araçları özelliği, araçların önceden hedeflediğiniz belirli platformlar için iyileştirildiğinden emin olmak için mükemmeldir. Ancak, hedeflemek istediğiniz tüm platformları bilmediğiniz zamanlar olabilir veya bazen .NET'in kendisi yeni bir platformu nasıl destekleyebileceğinizi öğrenir ve aracınızın orada da çalıştırılabilir olmasını istersiniz.

Aracının bu şekilde çalışmasını sağlamak için çalışma zamanı tanımlayıcısını any proje dosyanıza ekleyin:

<PropertyGroup>
  <RuntimeIdentifiers>
       linux-x64;
       linux-arm64;
       macos-arm64;
       win-x64;
       win-arm64;
       any
  </RuntimeIdentifiers>
</PropertyGroup>

Bu RuntimeIdentifier, platform uyumluluk denetiminin 'kökünde' yer alır ve herhangi bir platform için destek bildirdiğinden paketlenen araç, yürütülecek uyumlu bir .NET Çalışma Zamanı gerektiren, çerçeveye bağımlı, platforma bağımsız bir .NET DLL olan en uyumlu araç türüdür. Aracınızı oluşturmak için bir dotnet pack gerçekleştirdiğinizde, platforma özgü diğer paketlerin any ve üst düzey bildirim paketinin yanında RuntimeIdentifier için yeni bir paket görünür.

CLI introspection ile --cli-schema

Tüm CLI komutlarında yeni --cli-schema bir seçenek kullanılabilir. Kullanıldığında, çağrılan komut veya alt komut için CLI komut ağacının JSON gösterimini çıkarır. Bu, araç yazarları, kabuk entegrasyonu ve gelişmiş betik oluşturma için kullanışlıdır.

dotnet clean --cli-schema

Çıktı, komutun bağımsız değişkenlerinin, seçeneklerinin ve alt komutlarının yapılandırılmış, makine tarafından okunabilir bir açıklamasını sağlar:

{
  "name": "clean",
  "version": "10.0.100-dev",
  "description": ".NET Clean Command",
  "arguments": {
    "PROJECT | SOLUTION": {
      "description": "The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.",
      "arity": { "minimum": 0, "maximum": null }
    }
  },
  "options": {
    "--artifacts-path": {
      "description": "The artifacts path. All output from the project, including build, publish, and pack output, will go in subfolders under the specified path.",
      "helpName": "ARTIFACTS_DIR"
    }
  },
  "subcommands": {}
}

.NET Framework MSBuild ile .NET MSBuild görevlerini kullanma

MSBuild, .NET'in altında yatan derleme sistemidir ve hem projelerin derlenmesini (dotnet build ve dotnet pack gibi komutlarda görüldüğü üzere) hem de projeler hakkında genel bilgiler sağlayan bir sistem olarak işlev görür (dotnet list package gibi komutlarda görüldüğü üzere ve bir projenin nasıl yürütülmek istediğini keşfetmek amacıyla dotnet run gibi komutlar tarafından örtük olarak kullanılır).

CLI komutlarını çalıştırırken dotnet , kullanılan MSBuild sürümü .NET SDK'sı ile birlikte gönderilen sürümdür. Ancak, Visual Studio kullanırken veya MSBuild'i doğrudan çağırdığınızda, kullanılan MSBuild sürümü Visual Studio ile yüklenen sürümdür. Bu ortam farkının birkaç önemli sonucu vardır. En önemlisi, Visual Studio'da (veya aracılığıyla msbuild.exe) çalışan MSBuild bir .NET Framework uygulamasıyken, CLI'da dotnet çalışan MSBuild bir .NET uygulamasıdır. Bu, .NET üzerinde çalıştırılacak şekilde yazılan msbuild görevlerinin Visual Studio'da oluşturulurken veya kullanılırken msbuild.exekullanılamayacağı anlamına gelir.

.NET 10 msbuild.exe ve Visual Studio 2026'dan başlayarak .NET için oluşturulan MSBuild görevlerini çalıştırabilirsiniz. Bu, Visual Studio veya msbuild.exe kullanarak oluşturduğunuzda olduğu gibi dotnet CLI ile oluştururken de aynı MSBuild görevlerini kullanabileceğiniz anlamına gelir. Çoğu .NET kullanıcısı için bu hiçbir şeyi değiştirmez. Ancak özel MSBuild görevlerinin yazarları için bu, artık görevlerinizi .NET'i hedeflemek ve her yerde çalışmalarını sağlamak için yazabileceğiniz anlamına gelir. Bu değişikliğin amacı MSBuild görevlerini yazmayı ve paylaşmayı kolaylaştırmak ve görev yazarlarının .NET'teki en son özelliklerden yararlanmasına izin vermektir. Buna ek olarak, bu değişiklik hem .NET Framework'ün hem de .NET'in desteklenmesi ve MSBuild .NET Framework yürütme alanında örtük olarak kullanılabilen .NET Framework bağımlılıklarının sürümleriyle ilgilenmek için çoklu hedefleme görevleriyle ilgili zorlukları azaltır.

.NET görevlerini yapılandırma

Görev yazarları için bu yeni davranışı kabul etmek kolaydır. MSBuild'e görevinizi bildirmek için bildiriminizi UsingTask değiştirmeniz gerekir.

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
/>

Runtime="NET" ve TaskFactory="TaskHostFactory" öznitelikleri MSBuild altyapısına Görevi nasıl çalıştıracaklarını söyler:

• Runtime="NET" MSBuild'e Görevin .NET için derlendiğini bildirir (.NET Framework'ün aksine).
• TaskFactory="TaskHostFactory" MSBuild'e, Görev'i çalıştırmak için TaskHostFactory kullanmasını söyler. Bu, görevlerin işlem dışı çalıştırılmasına olanak tanıyan mevcut bir MSBuild özelliğidir.

Uyarılar ve performans ayarlama

Yukarıdaki örnek, MSBuild'de .NET görevlerini kullanmaya başlamanın en basit yoludur, ancak bazı sınırlamaları vardır. TaskHostFactory Görevleri her zaman işlem dışı çalıştırdığından, yeni .NET görevi her zaman MSBuild'den ayrı bir işlemde çalışır. Bu, MSBuild altyapısı ve görev işlem içi iletişim yerine işlemler arası iletişim (IPC) üzerinden iletişim kuracağından, görevi çalıştırmanın küçük bir yükü olduğu anlamına gelir. Çoğu görev için bu ek yük göz ardı edilebilir seviyedeyken, bir yapı işlemi sırasında birçok kez çalıştırılan veya çok fazla günlük kaydına neden olan görevler için bu ek yük daha önemli hale gelebilir.

Yalnızca biraz daha fazla çalışmayla, dotnet aracılığıyla çalışırken görevi süreç içinde çalışacak şekilde yapılandırabilirsiniz.

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
    Condition="$(MSBuildRuntimeType) == 'Full'"
/>
<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    Condition="$(MSBuildRuntimeType) == 'Core'"
/>

MSBuild'in Condition özelliği sayesinde, MSBuild'in .NET Framework'te (Visual Studio veya msbuild.exe) ya da .NET'te (CLI dotnet) çalıştığına bağlı olarak bir Görevi farklı şekilde yükleyebilirsiniz. Bu örnekte, Visual Studio veya msbuild.exeiçinde çalıştırılırken Görev işlem dışı çalışır, ancak CLI'da dotnet çalıştırılırken işlem halinde çalışır. Bu, CLI'da dotnet çalışırken en iyi performansı sağlarken, Görevin Visual Studio ve msbuild.exe'de kullanılmasına izin verir.

MSBuild'de .NET Görevleri kullanılırken dikkat edilmesi gereken küçük teknik sınırlamalar da vardır. Bunlardan en önemlisi, MSBuild Görevleri özelliğinin henüz işlem dışı çalışan .NET Görevleri için desteklenmemesidir Host Object . Başka bir deyişle, Göreviniz bir Konak Nesnesine dayanırsa, Visual Studio veya msbuild.exe'de çalıştırılırken çalışmayacaktır. Gelecek sürümlerde Konak Nesneleri için ek destek planlanıyor.

Dosya tabanlı uygulama geliştirmeleri

.NET 10, yayımlama desteği ve yerel AOT özellikleri de dahil olmak üzere dosya tabanlı uygulama deneyiminde önemli güncelleştirmeler sunar. Dosya tabanlı uygulamalara giriş için bkz. Dosya tabanlı uygulamalar ve C# programları oluşturma ve çalıştırma.

Yayımlama desteği ve yerel AOT ile gelişmiş dosya tabanlı uygulamalar

Dosya tabanlı uygulamalar artık komutuyla yerel yürütülebilir dosyalarda yayımlanmayı dotnet publish app.cs desteklediğinden, yerel yürütülebilir dosyalar olarak yeniden dağıtabileceğiniz basit uygulamalar oluşturmayı kolaylaştırır. Tüm dosya tabanlı uygulamalar artık varsayılan olarak yerel AOT'leri hedefler. Yerel AOT ile uyumlu olmayan paketleri veya özellikleri kullanmanız gerekiyorsa, .cs dosyanızdaki yönergesini #:property PublishAot=false kullanarak bunu devre dışı bırakabilirsiniz.

Dosya tabanlı uygulamalar ayrıca gelişmiş özellikler içerir:

• Proje referanslama:#:project yönergesi aracılığıyla projelere referans verme desteği.
• Çalışma zamanı yolu erişimi: Uygulama dosyası ve dizin yolları, çalışma zamanında System.AppContext.GetData aracılığıyla kullanılabilir.
• Gelişmiş shebang desteği: Uzantısız dosyalar için destek de dahil olmak üzere iyileştirilmiş shebang işleme sayesinde doğrudan kabuk yürütme.

Proje başvuru örneği

#:project ../ClassLib/ClassLib.csproj

var greeter = new ClassLib.Greeter();
var greeting = greeter.Greet(args.Length > 0 ? args[0] : "World");
Console.WriteLine(greeting);

Gelişmiş shebang desteği örneği

Artık doğrudan kabuktan çalıştırılacak yürütülebilir C# dosyaları oluşturabilirsiniz:

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

Uzantısız dosyalar için:

# 1. Create a single-file C# app with a shebang
cat << 'EOF' > hello.cs
#!/usr/bin/env dotnet
Console.WriteLine("Hello!");
EOF

# 2. Copy it (extensionless) into ~/utils/hello (~/utils is on my PATH)
mkdir -p ~/utils
cp hello.cs ~/utils/hello

# 3. Mark it executable
chmod +x ~/utils/hello

# 4. Run it directly from anywhere
cd ~
hello

Bu geliştirmeler, dosya tabanlı uygulamaları daha güçlü hale getirirken, hızlı betik oluşturma ve prototip oluşturma senaryoları için kolaylıklarını korur.

Yerel AOT hakkında daha fazla bilgi için bkz. .NET native AOT.

Çerçeve tarafından sağlanan paket başvurularının ayıklaması

.NET 10'dan başlayarak NuGet Denetimi özelliği, proje tarafından kullanılmayan çerçeve tarafından sağlanan paket başvurularını ayıklamak için kullanılabilir. Bu özellik, en son SDK'da >= .NET 10.0 hedefleyen bir projenin tüm frameworkleri için varsayılan olarak etkindir. Bu değişiklik, derleme işlemi sırasında geri yüklenen ve analiz edilen paketlerin sayısını azaltmaya yardımcı olur ve bu da daha hızlı derleme sürelerine ve daha az disk alanı kullanımına yol açabilir. Ayrıca NuGet Denetimi ve diğer bağımlılık tarama mekanizmalarından gelen hatalı pozitif sonuçların azalmasına da yol açabilir.

Bu özellik etkinleştirildiğinde, uygulamalarınızın oluşturulan .deps.json dosyalarının içeriğinde bir azalma görebilirsiniz. .NET çalışma zamanı tarafından sağlanan tüm paket başvuruları, oluşturulan bağımlılık dosyasından otomatik olarak kaldırılır. Doğrudan paket başvurusu ayıklama aralığı içindeyse, PrivateAssets="all" ve IncludeAssets="none" uygulanır.

Bu özellik listelenen TFM'ler için varsayılan olarak etkin olsa da, özelliğini RestoreEnablePackagePruning proje dosyanızda veya false dosyanızda olarak ayarlayarak devre dışı bırakabilirsiniz.

Daha tutarlı komut sırası

.NET 10'dan itibaren, CLI aracı, yaygın komutların hatırlanması ve yazılması daha kolay olsun diye yeni takma adlar eklenmiştir. Yeni komutlar aşağıdaki tabloda gösterilmiştir.

Yeni ilk isim formu	Şunun için takma ad
dotnet package add	dotnet add package
dotnet package list	dotnet list package
dotnet package remove	dotnet remove package
dotnet reference add	dotnet add reference
dotnet reference list	dotnet list reference
dotnet reference remove	dotnet remove reference

İsim öncelikli yeni formlar genel CLI standartlarıyla uyumlu olduğundan, dotnet CLI diğer araçlarla daha tutarlı hale gelmektedir. Fiil öncelikli formlar çalışmaya devam etse de, betiklerde ve belgelerde daha iyi okunabilirlik ve tutarlılık için ad öncelikli formları kullanmak daha iyidir.

CLI komutları, etkileşimli terminallerde varsayılan olarak etkileşimli moda geçer

Bayrağı --interactive artık etkileşimli terminallerdeki CLI komutları için varsayılan olarak etkindir. Bu değişiklik komutların kimlik bilgilerini dinamik olarak almasına veya bayrağın açıkça ayarlanmasına gerek kalmadan diğer etkileşimli davranışları gerçekleştirmesine olanak tanır. Etkileşimsiz senaryolar için --interactive false belirterek etkileşimi devre dışı bırakabilirsiniz.

Yerel kabuk sekme tamamlama betikleri

dotnet CLI artık dotnet completions script [SHELL] komutunu kullanarak popüler kabuklar için yerel sekme tamamlama betikleri oluşturmayı destekliyor. Desteklenen kabuklar bash, fish, nushell, powershell ve zsh içerir. Bu betikler, daha hızlı ve daha tümleşik sekme tamamlama özellikleri sağlayarak kullanılabilirliği artırır. Örneğin, PowerShell'de, aşağıdakini öğesine $PROFILEekleyerek tamamlamaları etkinleştirebilirsiniz:

dotnet completions script pwsh | Out-String | Invoke-Expression

Konsol uygulamaları yerel olarak kapsayıcı görüntüleri oluşturabilir

Konsol uygulamaları artık proje dosyasında dotnet publish /t:PublishContainer özelliğine gerek kalmadan <EnableSdkContainerSupport> aracılığıyla kapsayıcı görüntüleri oluşturabilir. Bu, konsol uygulamalarını ASP.NET Core ve Worker SDK uygulamalarının davranışıyla hizalar.

Kapsayıcıların görüntü biçimini açıkça denetleme

Yeni bir <ContainerImageFormat> özelliği, kapsayıcı görüntülerinin biçimini Docker veya OCI olarak açıkça ayarlamanıza olanak tanır. Bu özellik, temel görüntü biçimine ve kapsayıcının çok mimarili olup olmamasına bağlı olarak varsayılan davranışı geçersiz kılar.

'da Microsoft Test Platformu desteği dotnet test

.NET 10'dan başlayarak dotnet test yerel olarak destekler. Bu özelliği etkinleştirmek için global.json dosyanıza aşağıdaki yapılandırmayı ekleyin:

{
    "test": {
        "runner": "Microsoft.Testing.Platform"
    }
}

Daha fazla ayrıntı için Test Etme dotnet test bölümüne bakın.