ASP.NET Core Eğitimi: Native AOT API'lerini Ölçerek Yayınlamak

.NET Core Eğitimi: Native AOT için önce uygunluk envanteri çıkarın

Native AOT'ye geçmeden önce uygulamanın reflection, çalışma anında assembly yükleme ve dinamik kod üretme noktalarını bulun. Bunlar AOT derlemesinde ya kırpılır ya da çalışma anında desteklenmez. CI aşamasına aşağıdaki taramayı ekleyin; özellikle plugin yükleyen kod, Assembly.Load, Type.GetType, MakeGenericType ve expression derleme çağrılarını inceleyin. Bu yaklaşım bir .net core eğitimi içinde 'PublishAot=true' eklemekten daha değerlidir, çünkü başarısızlık çoğunlukla derleme anında değil, nadir kullanılan bir endpoint ilk çağrıldığında görünür.

rg -n --glob '*.cs'   'Assembly\.Load|Type\.GetType|Activator\.CreateInstance|MakeGenericType|Compile\(|GetMethod\('   src/

dotnet publish src/Catalog.Api/Catalog.Api.csproj   -c Release -r linux-x64 --self-contained true   -p:PublishAot=true -p:SuppressTrimAnalysisWarnings=false

Derleme çıktısındaki IL2026, IL2057 ve IL3050 uyarılarını hata kabul edin. IL2026, çağrılan kodun kırpma açısından ek metadata gerektirdiğini; IL3050 ise API'nin Native AOT ile uyumsuz olabildiğini işaret eder. Geçici olarak SuppressTrimAnalysisWarnings açmak yerine uyarıyı üreten metodu çağrı zinciriyle birlikte düzeltin. Örneğin bir serializer'ın yalnızca belirli modelleri işlemesi gerekiyorsa, tüm assembly'yi koruyan XML descriptor yerine System.Text.Json kaynak üretimiyle tam olarak bu model setini köklendirmek daha küçük ve denetlenebilir bir binary üretir.

ASP.NET Core Eğitimi: Reflection tabanlı JSON'u kaynak üretimiyle değiştirin

Minimal API'lerde en sık kaçan AOT bağımlılığı JSON metadata'sıdır. Varsayılan reflection serializer'ı JIT modunda modelin property bilgisini çalışma anında çıkarabilir; AOT binary'sinde bu metadata kırpılmış olabileceği için aynı endpoint hata verir. DTO'lar için JsonSerializerContext üretin ve resolver zincirine ekleyin. Aşağıdaki örnekte endpoint'in dönüş tipi, üreticinin statik olarak görebileceği OrderResponse ile sınırlıdır.

using System.Text.Json.Serialization;

[JsonSerializable(typeof(OrderResponse))]
[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
public partial class ApiJsonContext : JsonSerializerContext;

public sealed record OrderResponse(int Id, string Status, decimal Total);

var builder = WebApplication.CreateSlimBuilder(args);
builder.Services.ConfigureHttpJsonOptions(options =>
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, ApiJsonContext.Default));

var app = builder.Build();
app.MapGet("/orders/{id:int}", static (int id) =>
    TypedResults.Ok(new OrderResponse(id, "paid", 125.50m)));
app.Run();

Burada CreateSlimBuilder, varsayılan web host kaydındaki gereksiz servisleri azaltabildiği için AOT senaryosunda mantıklıdır; ancak mevcut uygulamadaki middleware'lerin otomatik kayıtlı olduğunu varsaymayın. OpenAPI, authentication veya MVC eklerseniz her birini ayrı smoke test ile doğrulayın. csharp eğitimi veya csharp kursu müfredatında bu ayrım önemlidir: kaynak üretimi sadece hız tercihi değildir, serializer'ın hangi tipler için metadata taşıyacağını derleme anında açıkça ilan eden bir bağımlılık sözleşmesidir.

Kırpma uyarılarını DynamicDependency ile değil tasarımla çözün

Bir controller keşfi, plugin altyapısı veya attribute taraması gerçekten reflection gerektiriyorsa, önce taranan tip kümesini daraltın. DynamicDependency son çare olmalıdır; aksi halde küçük bir reflection çağrısı yüzlerce tipin metadata'sını binary içinde tutabilir. Aşağıdaki kod, yalnızca gerçekten oluşturulan CsvExporter için public constructor bilgisini korur. Bu annotation'ı ekledikten sonra publish boyutunu ve uyarı sayısını CI artefact'ında kaydedin.

using System.Diagnostics.CodeAnalysis;

public static class ExporterFactory
{
    [DynamicDependency(
        DynamicallyAccessedMemberTypes.PublicConstructors,
        typeof(CsvExporter))]
    public static IExporter CreateCsvExporter() =>
        (IExporter)Activator.CreateInstance(typeof(CsvExporter))!;
}

Yaygın hata, generic repository veya validation kütüphanesinin assembly taramasını fark etmeden production'a taşımaktır. Örneğin services.Scan(...) ile tüm assembly'yi tarayan bir DI kaydı yerine kritik AOT servislerini açık kaydedin: services.AddSingleton<IPriceCalculator, PriceCalculator>(). Bu değişiklikten sonra uygulamanın DI grafiğini başlangıç testinde çalıştırın; sadece HTTP 200 kontrolü yetersizdir. Her endpoint'i çağıran bir integration test, özellikle ilk resolve edilen scoped servislerde eksik constructor metadata'sını ortaya çıkarır.

C# Eğitimi: JIT ve Native AOT ölçümünü aynı yük altında yapın

AOT sonucunu 'daha hızlı' diye etiketlemeyin; aynı container imajı tabanı, aynı CPU kotası, aynı endpoint ve aynı veriyle iki artefact üretin. İlk olarak self-contained JIT ve AOT publish edin. Ardından 30 saniyelik sabit süreli yükte p50, p95, istek/saniye, RSS ve CPU zamanı kaydedin. Tiered JIT, uzun yaşayan süreçte sıcak metotları yeniden derleyebilir; bu nedenle AOT soğuk başlangıçta avantaj gösterirken JIT uzun yükte aynı veya daha iyi p95 üretebilir.

dotnet publish src/Catalog.Api -c Release -r linux-x64   --self-contained true -o out/jit

dotnet publish src/Catalog.Api -c Release -r linux-x64   --self-contained true -p:PublishAot=true -o out/aot

bombardier -c 64 -d 30s   http://127.0.0.1:8080/orders/42

ps -o pid,rss,cmd -C Catalog.Api
perf stat -p $(pgrep -n Catalog.Api) -e cycles,instructions,cache-misses sleep 30

Başlangıç maliyetini ayrıca ölçün: process'i başlatın, yalnızca /healthz 200 dönene kadar curl ile polling yapın ve süreyi milisaniye olarak kaydedin. Çalışan süreçte dotnet-counters monitor --process-id PID System.Runtime ile GC Heap Size, Allocation Rate ve % Time in GC sayaçlarını toplayın. AOT sonrası allocation rate değişmediyse, beklenen bellek farkı gelmeyebilir; Native AOT JIT kod üretimini kaldırır, fakat LINQ zincirleri, string formatlama ve request başına DTO kopyaları tarafından üretilen managed allocation'ları kendiliğinden kaldırmaz. Bu nedenle c# eğitimi ve c# kursu katılımcılarının benchmark raporunda binary boyutu ile managed heap'i ayrı metrikler olarak yazması gerekir.

Entity Framework Eğitimi ve Blazor Eğitimi için AOT sınırları

Entity Framework Core kullanan API'lerde model oluşturma ve sorgu şekilleri AOT kararını doğrudan etkiler. Önce EF CLI sürümünüzün desteklediği seçenekleri doğrulayın, sonra derleme modelini üretin ve oluşan dosyayı source control'a değil CI üretimine bırakın. Native AOT sorgu ön derlemesini destekleyen EF Core paketlerinde aşağıdaki komut, compile-time model ve sorgu metadata'sı üretmek için kullanılabilir; dinamik olarak kurulan LINQ expression'ları ise bu modelle uyumlu olmayabilir.

dotnet ef dbcontext optimize   --project src/Catalog.Infrastructure   --startup-project src/Catalog.Api   --output-dir Generated --namespace Catalog.Infrastructure.Generated   --nativeaot

Bu noktada entity framework eğitimi, blazor eğitimi ve microsoft teknolojileri eğitimi içeriklerini aynı sepet gibi ele almak hatalıdır. Blazor tarafında reflection kullanan form doğrulama, serialization veya component discovery kodu varsa onu istemci ve sunucu publish hattında ayrı test edin; API'nin AOT uyumlu olması UI projesinin de aynı kısıtlara sahip olduğu anlamına gelmez. Bir .net core kursu laboratuvarında pratik kabul kriteri koyun: AOT publish sıfır çözülmemiş trim uyarısıyla bitecek, kritik endpoint'ler integration testten geçecek, ardından JIT ve AOT için aynı bombardier CSV çıktısı pull request'e eklenecek.

Sık Sorulan Sorular

ASP.NET Core eğitimi kapsamında Native AOT her Web API için uygun mu?

Hayır. Assembly'den plugin yükleme, runtime proxy üretimi, sınırsız reflection taraması veya kullanıcı girdisinden kurulan generic tipler varsa önce bu noktaları tasarımsal olarak sınırlayın. Kararı `dotnet publish -p:PublishAot=true -p:SuppressTrimAnalysisWarnings=false` çıktısındaki IL uyarıları, endpoint integration testleri ve gerçek yük ölçümüyle verin.

C# eğitimi için Native AOT ile System.Text.Json nasıl yapılandırılır?

Her request ve response DTO'sunu `[JsonSerializable]` ile bir `JsonSerializerContext` içine alın, sonra `ConfigureHttpJsonOptions` üzerinden `TypeInfoResolverChain` içine generated context'i ekleyin. Reflection fallback'e güvenmek yerine, yeni DTO eklendiğinde AOT publish ve endpoint testiyle metadata eksikliğini CI'da yakalayın.

Entity Framework eğitimi alırken Native AOT kullanan projede ne test etmeliyim?

Önce `dotnet ef dbcontext optimize --nativeaot` komutunun kullandığınız EF CLI ve paket sürümünde desteklenip desteklenmediğini doğrulayın. Ardından her repository sorgusunu gerçek provider ile integration testte çalıştırın; expression tree'yi çalışma anında birleştiren dinamik filtreler ve reflection tabanlı mapping kodu, yalnızca DbContext oluşturma testiyle yakalanmaz.

.net core kursu projelerinde AOT performans farkını hangi araçla ölçmeliyim?

HTTP yükü için `bombardier`, Linux CPU sayaçları için `perf stat`, managed runtime sayaçları için `dotnet-counters` kullanın. JIT ve AOT artefact'larını aynı runtime limiti ve aynı veriyle ısındırarak çalıştırın; p95 latency, requests/sec, RSS, Allocation Rate ve cold-start süresini tek tabloda karşılaştırın.