Dotnet | The .NET Blog

Python, TypeScript ve .NET ile azd Hook Yazma: Shell Script'lere Veda

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Tamamen .NET ile yazılmış bir projeniz olmasına rağmen azd hook’ları için Bash scriptleri yazmak zorunda kaldıysanız, bu acıyı iyi biliyorsunuzdur. Projenin geri kalanı C# iken, neden bir pre-provisioning adımı için shell sözdizimine geçiş yapmak zorunda kalınsın?

Bu hayal kırıklığı artık resmi bir çözüme kavuştu. Azure Developer CLI hook’lar için çok dilli destek yayımladı ve tam olarak duyulduğu kadar iyi.

Hook nedir?

Hook’lar, azd yaşam döngüsünün kritik noktalarında çalışan scriptlerdir — provisioning öncesi, deployment sonrası vb. azure.yaml içinde tanımlanır ve CLI’yi değiştirmeden özel mantık eklemenizi sağlar.

Önceden yalnızca Bash ve PowerShell destekleniyordu. Artık Python, JavaScript, TypeScript veya .NET kullanılabilir — azd geri kalanını otomatik olarak halleder.

Algılama nasıl çalışır

Yalnızca hook’u bir dosyaya yönlendirin; azd uzantıdan dili çıkarır:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Ek yapılandırma gerekmez. Uzantı belirsizse kind: python (veya ilgili dil) ile açıkça belirtebilirsiniz.

Dile göre önemli ayrıntılar

Python

Scriptin yanına (veya herhangi bir üst dizine) requirements.txt ya da pyproject.toml koyun. azd otomatik olarak sanal ortam oluşturur, bağımlılıkları kurar ve scripti çalıştırır.

JavaScript ve TypeScript

Aynı desen — script yakınına package.json koyun ve azd önce npm install çalıştırır. TypeScript için derleme adımı ve tsconfig.json gerekmeden npx tsx kullanılır.

.NET

İki mod mevcuttur:

Proje modu: Script yanında .csproj varsa azd otomatik olarak dotnet restore ve dotnet build çalıştırır.
Tek dosya modu: .NET 10+ sürümünde bağımsız .cs dosyaları dotnet run script.cs ile doğrudan çalıştırılabilir. Proje dosyası gerekmez.

Executor’a özgü yapılandırma

Her dil isteğe bağlı bir config bloğunu destekler:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET geliştiricileri için önemi

Hook’lar, azd tabanlı bir projede dil değiştirmeyi zorunlu kılan son yerdi. Artık uygulama kodu, altyapı scriptleri ve yaşam döngüsü hook’ları dahil tüm deployment pipeline’ı tek bir dilde yaşayabilir. Mevcut .NET yardımcı programlarını hook’larda yeniden kullanabilir, paylaşılan kütüphanelere referans verebilir ve shell script bakımından kurtulabilirsiniz.

Sonuç

Küçük görünse de azd günlük iş akışından çok fazla sürtünme kaldıran değişikliklerden biri. Hook’lar için çok dilli destek şu anda kullanılabilir — resmi gönderinde tam belgelere ulaşabilirsiniz.

Windows App Dev CLI v0.3: Terminalden F5 Hata Ayıklama ve Ajanlar için UI Otomasyonu

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Visual Studio’nun F5 deneyimi harika. Ama yalnızca paketlenmiş bir Windows uygulamasını başlatıp hata ayıklamak için VS’yi açmak — bir CI boru hattında, otomatik bir iş akışında veya bir yapay zeka ajanı testleri çalıştırırken — fazla ağır bir yük.

Windows App Development CLI v0.3 yayınlandı ve bunu iki temel özellikle doğrudan ele alıyor: winapp run ve winapp ui.

winapp run: Her yerden F5

winapp run paketlenmemiş bir uygulama klasörü ve manifest alır; VS’nin hata ayıklama başlatmasında yaptığı her şeyi yapar: loose paket kaydeder, uygulamayı başlatır ve yeniden dağıtımlar arasında LocalState‘i korur.

# Uygulamayı derleyin, ardından paketlenmiş uygulama olarak çalıştırın
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia ve daha fazlası için çalışır. Modlar hem geliştiriciler hem de otomatik iş akışları için tasarlanmıştır:

--detach: Başlatır ve hemen terminale kontrolü geri döndürür. CI için ideal.
--unregister-on-exit: Uygulama kapatıldığında kayıtlı paketi temizler.
--debug-output: OutputDebugString mesajlarını ve istisnaları gerçek zamanlı yakalar.

Yeni NuGet Paketi: Paketlenmiş uygulamalar için dotnet run

.NET geliştiricileri için yeni bir NuGet paketi var: Microsoft.Windows.SDK.BuildTools.WinApp. Kurulumdan sonra dotnet run tüm iç döngüyü yönetir: derleme, loose-layout paketi hazırlama, Windows’ta kayıt ve başlatma — tek adımda.

winapp init
# veya
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: Komut satırından UI Otomasyonu

Bu, ajan senaryolarını açan özellik. winapp ui, terminalden çalışan herhangi bir Windows uygulamasına (WPF, WinForms, Win32, Electron, WinUI3) tam UI Automation erişimi sağlar.

Yapılabilecekler:

Tüm üst düzey pencereleri listele
Herhangi bir pencerenin tam UI Automation ağacında gezin
Ad, tür veya otomasyon kimliğine göre öğe ara
Tıkla, çağır ve değer ayarla
Ekran görüntüsü al
Öğelerin görünmesini bekle — test senkronizasyonu için ideal

winapp ui ile winapp run‘ı birleştirmek, terminalden eksiksiz bir derleme → başlatma → doğrulama iş akışı sağlar. Bir ajan uygulamayı çalıştırabilir, UI durumunu inceleyebilir, programatik olarak etkileşime girebilir ve sonucu doğrulayabilir.

Diğer yenilikler

winapp unregister: Tamamlandığında yandan yüklenmiş paketi kaldırır.
winapp manifest add-alias: Terminalden adıyla uygulama başlatmak için takma ad ekler.
Sekme tamamlama: PowerShell tamamlamayı tek komutla yapılandırın.

Nasıl edinilir

winget install Microsoft.WinAppCli
# veya
npm install -g @microsoft/winappcli

CLI genel önizleme aşamasında. Tam belgeleme için GitHub deposuna, tüm ayrıntılar için orijinal duyuruya bakın.

Terminalinizi Serbest Bırakın: Aspire'ın Detached Modu İş Akışını Değiştiriyor

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Bir Aspire AppHost çalıştırdığınız her seferinde terminaliniz kayboluyor. Kilitli. Ctrl+C ile çıkana kadar meşgul. Hızlı bir komut çalıştırmanız mı gerekiyor? Yeni bir sekme açın. Logları kontrol etmek ister misiniz? Başka bir sekme. Bu küçük sürtünme hızla birikerek büyüyor.

Aspire 13.2 bunu düzeltiyor. James Newton-King tüm ayrıntıları yazdı ve dürüstçe söylemek gerekirse bu, çalışma şeklinizi anında değiştiren özelliklerden biri.

Detached mod: bir komut, terminal geri

aspire start

Bu, aspire run --detach için kısayol. AppHost’unuz arka planda başlıyor ve terminalinizi anında geri alıyorsunuz. Ekstra sekme yok. Terminal çoğullayıcı yok. Sadece prompt’unuz, hazır ve bekliyor.

Çalışanları yönetmek

İşte şu an — arka planda çalıştırmak yalnızca orada ne olduğunu gerçekten yönetebiliyorsanız işe yarıyor. Aspire 13.2 tam bunun için eksiksiz bir CLI komut seti sunuyor:

# Çalışan tüm AppHost'ları listele
aspire ps

# Belirli bir AppHost'un durumunu incele
aspire describe

# Çalışan bir AppHost'tan log akışı al
aspire logs

# Belirli bir AppHost'u durdur
aspire stop

Bu, Aspire CLI’ı gerçek anlamda bir süreç yöneticisine dönüştürüyor. Birden fazla AppHost başlatabilir, durumlarını kontrol edebilir, loglarını takip edebilir ve bunları kapatabilirsiniz — hepsi tek bir terminal oturumundan.

Isolated modla birleştirin

Detached mod, isolated modla doğal olarak uyum içinde çalışır. Port çakışması olmadan aynı projenin iki örneğini arka planda çalıştırmak ister misiniz?

aspire start --isolated
aspire start --isolated

Her biri rastgele portlar, ayrı secret’lar ve kendi yaşam döngüsü alıyor. Her ikisini görmek için aspire ps, işi bitenini kapatmak için aspire stop kullanın.

Bu neden kodlama ajanları için büyük bir gelişme

İşte gerçekten ilgi çekici olan kısım. Terminalinizde çalışan bir kodlama ajanı artık şunları yapabiliyor:

aspire start ile uygulamayı başlatmak
aspire describe ile durumunu sorgulamak
Sorunları teşhis etmek için aspire logs ile logları kontrol etmek
İşi bittiğinde aspire stop ile durdurmak

Terminal oturumunu kaybetmeden. Detached moddan önce, AppHost’unuzu çalıştıran bir ajan kendi terminaline erişimini kaybederdi. Artık başlatabilir, gözlemleyebilir, yineleyebilir ve temizleyebilir — tam olarak özerk bir ajanın çalışmasını isteyeceğiniz şekilde.

Aspire ekibi bunu benimsedi. aspire agent init çalıştırmak, ajanlara bu komutları öğreten bir Aspire skill dosyası kuruyor. Bu sayede Copilot’un kodlama ajanı gibi araçlar Aspire iş yüklerinizi kutudan çıkar çıkmaz yönetebiliyor.

Özet

Detached mod, basit bir bayrak kılığında gizlenmiş bir iş akışı yükseltmesi. Terminaller arasında bağlam geçişlerini bırakıyorsunuz, ajanlar kendilerini bloke etmekten kurtuluyor ve yeni CLI komutları çalışanlar hakkında gerçek görünürlük sağlıyor. Pratik, temiz ve günlük geliştirme döngüsünü belirgin biçimde daha akıcı hale getiriyor.

Tüm ayrıntılar için tam yazıyı okuyun ve aspire update --self ile Aspire 13.2’yi edinin.

.NET MAUI Maps'e Nihayet Pin Kümeleme Geldi — Tek Özellik, Sıfır Acı

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Yüz pin’li bir harita yüklediğinizde ve her şeyin okunaksız bir kümreye dönüştüğü o anı bilirsiniz, değil mi? Evet, .NET MAUI Maps deneyimi şimdiye kadar tam olarak buydu. Artık değil.

David Ortinau, .NET MAUI 11 Preview 3’ün Android ve iOS/Mac Catalyst üzerinde kutudan çıkar çıkmaz pin kümeleme sunduğunu duyurdu. Ve en iyi kısım — etkinleştirmek gülünç derecede basit.

Hepsini Yöneten Tek Özellik

<maps:Map IsClusteringEnabled="True" />

Hepsi bu kadar. Yakın pinler, sayı rozeti olan kümeler halinde gruplanır. Yakınlaştırın ve genişlerler. Uzaklaştırın ve daralırlar. Kullanıcıların modern bir haritadan beklediği türden davranış — ve artık tek bir özellikle elde ediyorsunuz.

Bağımsız Kümeleme Grupları

İşte ilginçleştiği yer burası. Tüm pinler birlikte kümelenmemelidir. Kahve dükkanları ve parklar farklı şeylerdir ve haritanız bunu bilmelidir.

ClusteringIdentifier özelliği, pinleri bağımsız gruplara ayırmanızı sağlar:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Aynı tanımlayıcıya sahip pinler birlikte kümelenir. Farklı tanımlayıcılar, coğrafi olarak yakın olsalar bile bağımsız kümeler oluşturur. Tanımlayıcı yok mu? Varsayılan grup. Temiz ve öngörülebilir.

Küme Tap’larını Yönetme

Bir kullanıcı kümeye dokunduğunda, ihtiyacınız olan her şeyle birlikte bir ClusterClicked olayı alırsınız:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Varsayılan kümeye-yakınlaştırma davranışını bastır:
 // e.Handled = true;
};

Olay argümanları size Pins (kümedeki pinler), Location (coğrafi merkez) ve Handled (varsayılanı geçersiz kılmak istiyorsanız true olarak ayarlayın) sunar. Basit, pratik, tam olarak beklediğiniz şey.

Bilmeye Değer Platform Ayrıntıları

Android’de kümeleme, zoom değişikliklerinde yeniden hesaplanan özel ızgara tabanlı bir algoritma kullanır — harici bağımlılık yok. iOS ve Mac Catalyst’te, sorunsuz, platform-native animasyonlar anlamına gelen MapKit’ten yerel MKClusterAnnotation desteğinden yararlanır.

Bu, MAUI ekibinin doğru kararı verdiği durumlardan biri — mantıklı olduğunda platforma güvenmek.

Neden Önemli?

Pin kümeleme, .NET MAUI’de en çok talep edilen özelliklerden biri olmuştur (issue #11811), ve bunun iyi bir nedeni var. Haritada konumları gösteren her uygulama — teslimat takibi, mağaza bulucu, gayrimenkul — buna ihtiyaç duyar. Daha önce bunu kendiniz oluşturmanız veya üçüncü taraf bir kütüphane getirmeniz gerekiyordu. Artık yerleşik.

Cross-platform mobil uygulamalar geliştiren .NET geliştiricileri için bu, MAUI’yi harita yoğun senaryolar için gerçekten pratik bir tercih haline getiren türden bir yaşam kalitesi iyileştirmesi.

Başlarken

.NET 11 Preview 3‘ü kurun ve .NET MAUI iş yükünü güncelleyin. Maps örneği, hemen oynayabileceğiniz yeni bir Clustering sayfası içeriyor.

Gidin ve onunla bir şeyler oluşturun — haritalarınızın nihayet nefes almasına izin verin.

.NET Nisan 2026 Bakım Güncellemesi — Bugün Uygulamanız Gereken Güvenlik Yamaları

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

.NET ve .NET Framework için Nisan 2026 bakım güncellemeleri yayımlandı ve bu sürüm yakında uygulamak isteyeceğiniz güvenlik düzeltmelerini içeriyor. İki uzaktan kod yürütme (RCE) açığı dahil olmak üzere altı CVE yamalandı.

Neler yamalandı

İşte hızlı özet:

CVE	Tür	Etkileyen
CVE-2026-26171	Güvenlik Özelliği Atlatma	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Uzaktan Kod Yürütme	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Uzaktan Kod Yürütme	.NET 10, 9, 8
CVE-2026-32203	Hizmet Reddi	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Hizmet Reddi	.NET Framework 3.0–4.8.1
CVE-2026-32226	Hizmet Reddi	.NET Framework 2.0–4.8.1

İki RCE CVE’si (CVE-2026-32178 ve CVE-2026-33116) en geniş .NET sürümü yelpazesini etkiliyor ve öncelikli olarak ele alınmalı.

Güncellenen sürümler

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Tümü olağan kanallar aracılığıyla mevcut — dotnet.microsoft.com, MCR’deki container imajları ve Linux paket yöneticileri.

Ne yapmalısınız

Projelerinizi ve CI/CD pipeline’larınızı en son yama sürümlerine güncelleyin. Container çalıştırıyorsanız, en son imajları çekin. .NET Framework kullanıyorsanız, ilgili yamalar için .NET Framework sürüm notlarına bakın.

Üretimde .NET 10 çalıştıranlar için (şu an güncel sürüm), 10.0.6 zorunlu bir güncellemedir. Bu LTS sürümlerindeyseniz .NET 9.0.15 ve .NET 8.0.26 için de aynısı geçerli. İki RCE açığı ertelenerek geçiştirilebilecek bir şey değildir.

Azure MCP Server 2.0 Yayınlandı — Self-Hosted Agentic Bulut Otomasyonu Artık Burada

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Son zamanlarda MCP ve Azure ile bir şeyler geliştirdiyseniz, yerel deneyimin gayet iyi çalıştığını muhtemelen zaten biliyorsunuzdur. Bir MCP server bağlayın, AI agent’ınızın Azure kaynaklarıyla konuşmasına izin verin, devam edin. Ama bu kurulumu bir ekip genelinde paylaşmanız gerektiğinde? İşte orada işler karmaşıklaşıyordu.

Artık değil. Azure MCP Server 2.0 kararlı sürüme ulaştı ve başlık özelliği tam olarak kurumsal ekiplerin istediği şey: self-hosted uzak MCP server desteği.

Azure MCP Server nedir?

Kısa bir hatırlatma. Azure MCP Server, Model Context Protocol spesifikasyonunu uygular ve Azure yeteneklerini AI agent’larının çağırabileceği yapılandırılmış, keşfedilebilir araçlar olarak sunar. Agent’ınız ile Azure arasında standartlaştırılmış bir köprü olarak düşünebilirsiniz — sağlama, dağıtım, izleme, tanılama, hepsi tek tutarlı bir arayüz üzerinden.

Rakamlar kendisi konuşuyor: 57 Azure servisi genelinde 276 MCP aracı. Bu ciddi bir kapsam.

Büyük haber: self-hosted uzak dağıtımlar

Şöyle ki. MCP’yi kendi makinenizde yerel olarak çalıştırmak geliştirme ve deneyler için sorun değil. Ama gerçek bir ekip senaryosunda şunlara ihtiyacınız var:

Geliştiriciler ve dahili agent sistemleri için paylaşımlı erişim
Merkezi yapılandırma (tenant bağlamı, abonelik varsayılanları, telemetri)
Kurumsal ağ ve politika sınırları
CI/CD pipeline’larına entegrasyon

Azure MCP Server 2.0 tüm bunları ele alıyor. HTTP tabanlı taşıma, uygun kimlik doğrulama ve tutarlı yönetişimle merkezi olarak yönetilen bir dahili servis olarak dağıtabilirsiniz.

Kimlik doğrulama için iki sağlam seçenek var:

Managed Identity — Microsoft Foundry ile birlikte çalışırken
On-Behalf-Of (OBO) akışı — Azure API’lerini oturum açmış kullanıcının bağlamını kullanarak çağıran OpenID Connect delegasyonu

Bu OBO akışı, .NET geliştiricileri olarak bizim için özellikle ilginç. Agentic iş akışlarınızın aşırı ayrıcalıklı bir servis hesabı yerine kullanıcının gerçek izinleriyle çalışabileceği anlamına geliyor. En az ayrıcalık ilkesi, doğrudan yerleşik.

Güvenlik güçlendirmesi

Bu yalnızca bir özellik sürümü değil — aynı zamanda bir güvenlik sürümü. 2.0 sürümü şunları ekliyor:

Daha güçlü endpoint doğrulaması
Sorgu odaklı araçlarda injection kalıplarına karşı koruma
Geliştirme ortamları için daha sıkı izolasyon kontrolleri

MCP’yi paylaşımlı bir servis olarak sunacaksanız, bu güvenceler önemli. Çok önemli.

Nerede kullanabilirsiniz?

İstemci uyumluluk hikayesi geniş. Azure MCP Server 2.0 şunlarla çalışıyor:

IDE’ler: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agent’ları: GitHub Copilot CLI, Claude Code
Bağımsız: basit kurulumlar için yerel server
Self-hosted uzak: 2.0’ın yeni yıldızı

Ayrıca düzenlenmiş dağıtımlar için kritik olan Azure US Government ve 21Vianet tarafından işletilen Azure için sovereign bulut desteği de var.

Bu .NET geliştiricileri için neden önemli

.NET ile agentic uygulamalar geliştiriyorsanız — ister Semantic Kernel, ister Microsoft Agent Framework, ister kendi orkestrasyon çözümünüz — Azure MCP Server 2.0, agent’larınızın Azure altyapısıyla etkileşime geçmesi için üretime hazır bir yol sunuyor. Özel REST wrapper’ları yok. Servise özgü entegrasyon kalıpları yok. Sadece MCP.

Birkaç gün önce yayınlanan MCP Apps için fluent API ile birleşince .NET MCP ekosistemi hızla olgunlaşıyor.

Başlarken

Kendi yolunuzu seçin:

GitHub Repo — kaynak kodu, dokümantasyon, her şey
Docker Image — container’lı dağıtım
VS Code Extension — IDE entegrasyonu
Self-hosting rehberi — 2.0’ın öne çıkan özelliği

Sonuç

Azure MCP Server 2.0, demoda gösterişli görünmeyen ama pratikte her şeyi değiştiren altyapı yükseltmesi türünden. Uygun kimlik doğrulama, güvenlik güçlendirmesi ve sovereign bulut desteğiyle self-hosted uzak MCP, gerçek ekiplerin Azure üzerinde gerçek agentic iş akışları oluşturması için hazır olduğu anlamına geliyor. “Kurumsal kullanıma hazır” sinyalini bekliyordunuz — işte bu.

.NET Aspire 13.2 AI Ajanınızın En İyi Dostu Olmak İstiyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

AI kodlama ajanınızın sağlam bir kod yazdığı, heyecanlandığınız ve ardından uygulamayı çalıştırmaya çalışırken her şeyin dağıldığı o anı biliyor musunuz? Port çakışmaları, hayalet süreçler, yanlış ortam değişkenleri — ve bir anda ajanınız özellik geliştirmek yerine başlangıç sorunlarını çözmek için token harcamaya başlıyor.

Aspire ekibi tam da bu sorun hakkında gerçekten düşünceli bir yazı yayımladı ve cevapları ikna edici: Aspire 13.2 yalnızca insanlar için değil, AI ajanları için de tasarlanmış.

Sorun gerçek

AI ajanları kod yazmakta inanılmaz derecede başarılı. Ancak çalışan bir full-stack uygulama göndermek, dosya oluşturmaktan çok daha fazlasını gerektiriyor. Servisleri doğru sırayla başlatmanız, portları yönetmeniz, ortam değişkenlerini ayarlamanız, veritabanlarını bağlamanız ve bir şeyler bozulduğunda geri bildirim almanız gerekiyor. Şu an çoğu ajan bunların hepsini deneme-yanılma yoluyla hallediypr — komutları çalıştırıyor, hata çıktısını okuyor, yeniden deniyor.

Markdown talimatları, özel skill’ler ve prompt’lar ekleyerek onlara rehberlik etmeye çalışıyoruz, ancak bunlar öngörülemez, derlenemiyor ve ayrıştırılmaları bile token harcıyor. Aspire ekibi temel içgörüyü doğru yakaladı: ajanların daha fazla Markdown’a değil, derleyicilere ve yapılandırılmış API’lara ihtiyacı var.

Ajan altyapısı olarak Aspire

Aspire 13.2’nin ajansal geliştirme masasına getirdikleri:

Tüm yığınınız yazılı kodda. AppHost, tam topolojinizi — API, frontend, veritabanı, önbellek — derlenebilir TypeScript veya C# olarak tanımlıyor:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Bir ajan, uygulama topolojisini anlamak, kaynak eklemek, bağlantıları oluşturmak ve doğrulamak için derlemek amacıyla bunu okuyabilir. Derleyici bir şeyin yanlış olduğunu anında söylüyor. Tahmin yok, yapılandırma dosyalarıyla deneme-yanılma yok.

Her şeyi yöneten tek komut. Ajanların docker compose up, npm run dev ve veritabanı başlangıç betikleri arasında denge kurması yerine tek yapmaları gereken şey aspire start. Tüm kaynaklar doğru sırayla, doğru portlarda, doğru yapılandırmayla başlıyor. Uzun süre çalışan süreçler ajanı engellemez — bunları Aspire yönetiyor.

Paralel ajanlar için isolated mod. --isolated seçeneğiyle her Aspire çalıştırması kendi rastgele portlarını ve ayrı user secret’larını alıyor. Git worktree’lerinde çalışan birden fazla ajanınız mı var? Çakışmayacaklar. Bu, paralel ortamlar açan VS Code’un background agent’ları gibi araçlar için çok büyük bir gelişme.

Telemetri aracılığıyla ajan gözleri. İşte burada gerçekten güçlü oluyor. Aspire CLI, geliştirme sırasında tam OpenTelemetry verilerini açığa çıkarıyor — trace’ler, metrikler, yapılandırılmış loglar. Ajanınız yalnızca konsol çıktısını okuyup en iyisini ummak zorunda değil. Başarısız bir isteği servisler arasında izleyebilir, yavaş endpoint’lerin profilini çıkarabilir ve neyin tam olarak nerede bozulduğunu saptayabilir. Bu, geliştirme döngüsünde üretim kalitesinde gözlemlenebilirlik demek.

Bowling koruma bandı analojisi

Aspire ekibi harika bir analoji kullanıyor: Aspire’ı AI ajanları için bowling koruma bantları olarak düşünün. Ajan mükemmel olmasa da (ve olmayacak), bantlar onu oluktan atmaktan koruyor. Yığın tanımı yanlış yapılandırmayı önlüyor, derleyici hataları yakalıyor, CLI süreç yönetimini üstleniyor ve telemetri geri bildirim döngüsünü sağlıyor.

Bunu Playwright CLI gibi bir şeyle birleştirdiğinizde, ajanınız uygulamanızı gerçekten kullanabilir — akışlara tıklayabilir, DOM’u kontrol edebilir, telemetride kırık şeyleri görebilir, kodu düzeltebilir, yeniden başlatabilir ve tekrar test edebilir. Derle, çalıştır, gözlemle, düzelt. Bu, peşinden koştuğumuz özerk geliştirme döngüsü.

Başlarken

Aspire’a yeni misiniz? CLI’ı get.aspire.dev adresinden yükleyin ve başlangıç rehberini takip edin.

Zaten Aspire kullanıyor musunuz? 13.2’yi almak için aspire update --self komutunu çalıştırın, ardından favori kodlama ajanınızı repoya yönlendirin. Aspire’ın koruma bantlarıyla ne kadar daha ileri gittiğini görünce şaşırabilirsiniz.

Özet

Aspire 13.2 artık sadece bir dağıtık uygulama framework’ü değil — temel ajan altyapısına dönüşüyor. Yapılandırılmış yığın tanımları, tek komutla başlangıç, izole paralel çalıştırmalar ve gerçek zamanlı telemetri, AI ajanlarına kod yazmaktan uygulama göndermek için tam olarak ihtiyaç duydukları şeyleri veriyor.

Tüm ayrıntılar ve demo videolar için Aspire ekibinin tam yazısını okuyun.

Aspire'ın Isolated Modu Paralel Geliştirmedeki Port Çakışma Kabusu'nu Çözüyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aynı projenin iki örneğini aynı anda çalıştırmayı hiç denediniz mi? O acıyı bilirsiniz. Port 8080 zaten kullanımda. Port 17370 alınmış. Bir şeyleri kapatın, yeniden başlatın, ortam değişkenlerini dengeleyin — bu, üretkenliği mahveden bir durum.

Bu sorun daha da kötüleşiyor, iyileşmiyor. AI ajanlar bağımsız çalışmak için git worktree’ler oluşturuyor. Background agent’lar ayrı ortamlar başlatıyor. Geliştiriciler özellik dalları için aynı repoyu iki kez checkout yapıyor. Bu senaryoların her biri aynı engelle karşılaşıyor: aynı uygulamanın iki örneği aynı portlar için çarpışıyor.

Aspire 13.2 bunu tek bir bayrakla çözüyor. Aspire ekibinden James Newton-King tüm ayrıntıları yazdı ve bu, “bunu neden daha önce yoktu?” diye düşündüren özelliklerden biri.

Çözüm: `--isolated`

aspire run --isolated

Hepsi bu. Her çalıştırma şunları alıyor:

Rastgele portlar — örnekler arasında artık çakışma yok
İzole user secret’lar — bağlantı dizeleri ve API anahtarları örnek başına ayrı kalıyor

Manuel port yeniden ataması yok. Ortam değişkeni dengeleme yok. Her çalıştırma otomatik olarak taze, çakışmasız bir ortam alıyor.

Bunun parladığı gerçek senaryolar

Çoklu checkout’lar. Bir dizinde özellik dalı, başka bir dizinde hata düzeltmesi var:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Her ikisi de çakışma olmadan çalışıyor. Dashboard neyin nerede çalıştığını gösteriyor.

VS Code’daki background agent’lar. Copilot Chat’in background agent’ı kodunuz üzerinde bağımsız çalışmak için bir git worktree oluşturduğunda, Aspire AppHost’unuzu çalıştırması gerekebilir. --isolated olmadan, bu birincil worktree’nizle port çakışmasına yol açar. Bununla birlikte her iki örnek de çalışır.

aspire agent init ile birlikte gelen Aspire skill’i, worktree’lerde çalışırken ajanlara otomatik olarak --isolated kullanmalarını talimatlandırıyor. Dolayısıyla Copilot’un background agent’ı bunu kutudan çıkar çıkmaz halledebilmeli.

Geliştirmeyle eş zamanlı entegrasyon testleri. Özellik geliştirmeye devam ederken canlı bir AppHost’a karşı test çalıştırmanız mı gerekiyor? Isolated mod, her bağlama kendi portlarını ve yapılandırmasını veriyor.

Arka planda nasıl çalışıyor

--isolated geçirdiğinizde, CLI çalıştırma için benzersiz bir örnek kimliği oluşturuyor. Bu iki davranışı yönlendiriyor:

Port rastgeleleştirmesi — AppHost yapılandırmanızda tanımlanan öngörülebilir portlara bağlanmak yerine, isolated mod her şey için — dashboard, servis endpoint’leri, hepsi — rastgele uygun portlar seçiyor. Servis keşfi otomatik olarak ayarlanıyor, bu nedenle servisler hangi portlara düşerlerse düşsünler birbirlerini buluyor.
Secret izolasyonu — Her izole çalıştırma, örnek kimliğiyle anahtarlanan kendi user secret deposunu alıyor. Bir çalıştırmadan bağlantı dizeleri ve API anahtarları diğerine sızmıyor.

Kodunuzun değiştirilmesi gerekmiyor. Aspire’ın servis keşfi, endpoint’leri çalışma zamanında çözümlüyor, bu nedenle port atamasından bağımsız olarak her şey doğru şekilde bağlanıyor.

Ne zaman kullanmalı

Aynı AppHost’un birden fazla örneğini aynı anda çalıştırırken --isolated kullanın — ister paralel geliştirme, ister otomatik testler, ister AI ajanları, ister git worktree’ler olsun. Tahmin edilebilir portları tercih ettiğiniz tek örnekli geliştirme için, normal aspire run hâlâ gayet iyi çalışıyor.

Özet

Isolated mod, gerçek ve giderek yaygınlaşan bir sorunu çözen küçük bir özellik. AI destekli geliştirme bizi daha fazla paralel iş akışına — birden fazla ajan, birden fazla worktree, birden fazla bağlam — doğru iterken, portlar için çakışmadan yeni bir örnek başlatabilme yeteneği vazgeçilmez hale geliyor.

Tüm teknik ayrıntılar için tam yazıyı okuyun ve 13.2’yi almak için aspire update --self ile deneyin.

Azure Functions Üzerindeki MCP Server'larınızı Foundry Agent'larına Bağlayın — İşte Nasıl Yapılır

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP ekosistemi hakkında sevdiğim bir şey var: server’ınızı bir kez oluşturuyorsunuz ve her yerde çalışıyor. VS Code, Visual Studio, Cursor, ChatGPT — her MCP istemcisi araçlarınızı keşfedip kullanabiliyor. Şimdi Microsoft bu listeye bir tüketici daha ekliyor: Foundry agent’ları.

Azure SDK ekibinden Lily Ma, Microsoft Foundry agent’larıyla Azure Functions’a dağıtılmış MCP server’larını bağlamaya dair pratik bir kılavuz yayımladı. Zaten bir MCP server’ınız varsa, bu tamamen katma değer — yeniden yapılandırma gerekmiyor.

Bu Kombinasyon Neden Mantıklı?

Azure Functions, MCP server’larını barındırmak için ölçeklenebilir altyapı, yerleşik auth ve sunucusuz faturalama sunuyor. Microsoft Foundry ise akıl yürütebilen, plan yapabilen ve eylemler gerçekleştirebilen AI agent’ları sağlıyor. İkisini birleştirmek, özel araçlarınızın — veritabanı sorgulama, iş API’si çağrısı, doğrulama mantığı çalıştırma — kurumsal AI agent’larının özerk olarak keşfedip kullanabileceği yetenekler haline gelmesi anlamına geliyor.

Önemli nokta: MCP server’ınız aynı kalıyor. Yalnızca Foundry’yi başka bir tüketici olarak ekliyorsunuz. VS Code kurulumunuzda çalışan araçların aynısı artık ekibinizin veya müşterilerinizin etkileşime girdiği bir AI agent’ına güç veriyor.

Kimlik Doğrulama Seçenekleri

Yazının gerçek değer kattığı yer burası. Senaryonuza bağlı olarak dört auth yöntemi:

Yöntem	Kullanım Senaryosu
Key tabanlı (varsayılan)	Geliştirme veya Entra auth olmayan server’lar
Microsoft Entra	Yönetilen kimliklerle üretim
OAuth identity passthrough	Her kullanıcının bireysel olarak kimlik doğruladığı üretim
Kimlik doğrulamasız	Geliştirme/test veya yalnızca genel veriler

Üretim için, agent kimliğiyle Microsoft Entra önerilen yoldur. OAuth identity passthrough, kullanıcı bağlamının önemli olduğu durumlar içindir — agent kullanıcıların giriş yapmasını ister ve her istek kullanıcının kendi token’ını taşır.

Kurulum

Üst düzey akış:

MCP server’ınızı Azure Functions’a dağıtın — .NET, Python, TypeScript ve Java için örnekler mevcut
Function app’inizde yerleşik MCP kimlik doğrulamasını etkinleştirin
Endpoint URL’nizi alın — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
MCP server’ı Foundry’de araç olarak ekleyin — portaldaki agent’ınıza gidin, yeni bir MCP aracı ekleyin, endpoint ve kimlik bilgilerini sağlayın

Ardından araçlarınızdan birini tetikleyecek bir prompt göndererek Agent Builder playground’unda test edin.

Değerlendirmem

Buradaki kompozisyon hikayesi gerçekten güçleniyor. MCP server’ınızı .NET’te (veya Python, TypeScript, Java’da) bir kez oluşturun, Azure Functions’a dağıtın ve her MCP uyumlu istemci onu kullanabilsin — kodlama araçları, chat uygulamaları ve artık kurumsal AI agent’ları. Bu, gerçekten işleyen bir “bir kez yaz, her yerde kullan” pattern’ı.

.NET geliştiricileri için özellikle, Azure Functions MCP extension bunu kolaylaştırıyor. Araçlarınızı Azure Functions olarak tanımlayın, dağıtın ve Azure Functions’ın sağladığı tüm güvenlik ve ölçeklendirme özellikleriyle birlikte üretim kalitesinde bir MCP server’ınız olsun.

Son Söz

Azure Functions üzerinde çalışan MCP araçlarınız varsa, bunları Foundry agent’larına bağlamak hızlı bir kazanımdır — özel araçlarınız, server’ın kendisinde hiçbir kod değişikliği yapmadan ve uygun auth ile kurumsal AI yeteneklerine dönüşür.

Her kimlik doğrulama yöntemi için adım adım talimatlar için tam kılavuzu okuyun ve üretim kurulumları için ayrıntılı belgeleri inceleyin.

GitHub Copilot'un Modernizasyon Değerlendirmesi, Henüz Kullanmadığınız En İyi Göç Aracı

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Eski bir .NET Framework uygulamasını modern .NET’e taşımak, herkesin yapması gerektiğini bildiği ama kimsenin başlamak istemediği işlerden biri. Bu hiçbir zaman sadece “hedef framework’ü değiştir” meselesi değildir. Ortadan kalkan API’lar, artık mevcut olmayan paketler, tamamen farklı çalışan hosting modelleri ve neyin container’a alınacağı, neyin yeniden yazılacağı, neyin olduğu gibi bırakılacağına dair binlerce küçük karar var.

Jeffrey Fritz, GitHub Copilot’un modernizasyon değerlendirmesine derin bir dalış yayımladı ve dürüst olmak gerekirse? Bu, .NET için gördüğüm en iyi göç araçları. Kod oluşturma nedeniyle değil — bu artık herkes için temel gereksinim. Ürettiği değerlendirme belgesi nedeniyle.

Bu sadece bir kod öneri motoru değil

VS Code uzantısı bir Değerlendir → Planla → Uygula modeli izliyor. Değerlendirme aşaması tüm kod tabanınızı analiz ediyor ve her şeyi yakalayan yapılandırılmış bir belge üretiyor: neyin değişmesi gerektiği, hangi Azure kaynaklarının sağlanacağı, hangi dağıtım modelinin kullanılacağı. Aşağıdaki her şey — altyapı-kodu, containerlaştırma, dağıtım manifestoları — değerlendirmenin bulduklarından akıyor.

Değerlendirme, projenizde .github/modernize/assessment/ altında saklanıyor. Her çalıştırma bağımsız bir rapor üretiyor, böylece bir geçmiş oluşturabilir ve sorunları düzelttikçe göç pozisyonunuzun nasıl geliştiğini takip edebilirsiniz.

Başlamanın iki yolu

Önerilen Değerlendirme — hızlı yol. Seçilmiş alanlardan birini seçin (Java/.NET Yükseltme, Bulut Hazırlığı, Güvenlik) ve yapılandırmaya dokunmadan anlamlı sonuçlar alın. Uygulamanızın nerede durduğuna ilk bakış için harika.

Özel Değerlendirme — hedefli yol. Neyin analiz edileceğini tam olarak yapılandırın: hedef hesaplama (App Service, AKS, Container Apps), hedef işletim sistemi, containerlaştırma analizi. Göç yaklaşımlarını yan yana karşılaştırmak için birden fazla Azure hedefi seçin.

Bu karşılaştırma görünümü gerçekten yararlı. App Service için 3 zorunlu sorunu olan bir uygulamanın AKS için 7 sorunu olabilir. Her ikisini de görmek, bir göç yoluna bağlanmadan önce hosting kararını yönlendirmeye yardımcı oluyor.

Sorun dökümü uygulanabilir

Her sorun bir kritiklik düzeyiyle geliyor:

Zorunlu — düzeltilmeli, yoksa göç başarısız olur
Olası — göçü etkileyebilir, insan değerlendirmesi gerektirir
İsteğe bağlı — önerilen iyileştirmeler, göçü engellemez

Ve her sorun etkilenen dosyalara ve satır numaralarına bağlantı veriyor, neyin yanlış olduğunu ve neden hedef platformunuz için önemli olduğunu ayrıntılı açıklıyor, somut düzeltme adımları sunuyor (sadece “bunu düzelt” değil) ve resmi belgelere bağlantılar içeriyor.

Bireysel sorunları geliştiricilere verebilir ve harekete geçmek için ihtiyaç duydukları her şeye sahip olurlar. Bu, “bir sorun var” diyen bir araç ile nasıl çözüleceğini söyleyen bir araç arasındaki farktır.

Kapsanan yükseltme yolları

.NET için özellikle:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Her yükseltme yolunun, hangi API’ların kaldırıldığını, hangi desenlerin doğrudan eşdeğerinin bulunmadığını ve hangi güvenlik sorunlarının ele alınması gerektiğini bilen algılama kuralları var.

Birden fazla uygulamayı yöneten ekipler için çok-repo toplu değerlendirmeleri destekleyen bir CLI de var — tüm repoları klonlayın, hepsini değerlendirin, uygulama başına raporlar artı toplu portföy görünümü alın.

Benim düşüncem

Eski .NET Framework uygulamalarının üzerinde oturuyorsanız (ve gerçekçi olalım, çoğu kurumsal ekip oturuyor), bu başlamak için tek araçtır. Değerlendirme belgesi tek başına zamana değer — belirsiz bir “modernize etmeliyiz"i, somut ve önceliklendirilmiş, net ileriye dönük yolları olan bir iş öğeleri listesine dönüştürür.

İş birliğine dayalı iş akışı da akıllıca: değerlendirmeleri dışa aktarın, ekibinizle paylaşın, yeniden çalıştırmadan içe aktarın. Karar vericilerin araçları çalıştıranlar olmadığı mimari incelemeler? Karşılandı.

Sonuç

GitHub Copilot’un modernizasyon değerlendirmesi, .NET göçünü korkunç, tanımsız bir projeden yapılandırılmış, izlenebilir bir sürece dönüştürüyor. Nerede durduğunuzu görmek için önerilen değerlendirmeyle başlayın, ardından Azure hedeflerini karşılaştırmak ve göç planınızı oluşturmak için özel değerlendirmeleri kullanın.

Tam anlatımı okuyun ve kendi kod tabanınızda denemek için VS Code uzantısını alın.

MCP Uygulamaları Fluent API Kazandı — .NET'te Üç Adımda Zengin AI Araç Arayüzleri Oluşturun

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP araçları, AI agent’larına yetenekler kazandırmak için harika. Peki ya aracınızın kullanıcıya bir şey göstermesi gerekiyorsa — bir dashboard, bir form, etkileşimli bir görselleştirme? MCP Apps tam bu noktada devreye giriyor ve çok daha kolay hale geldi.

Azure SDK ekibinden Lilian Kasem, .NET Azure Functions’daki MCP Apps için yeni fluent yapılandırma API’sini tanıttı ve bu, neden başından beri bu kadar basit olmadığını düşündüren türden bir geliştirici deneyimi iyileştirmesi.

MCP Apps Nedir?

MCP Apps, araçların kendi UI görünümlerini, statik varlıklarını ve güvenlik kontrollerini taşımasına izin vererek Model Context Protocol’ü genişletir. MCP aracınız yalnızca metin döndürmek yerine tam HTML deneyimleri render edebilir — etkileşimli dashboard’lar, veri görselleştirmeleri, yapılandırma formları — bunların hepsi AI agent’ları tarafından çağrılabilir ve MCP istemcileri tarafından kullanıcılara sunulur.

Sorun şuydu: tüm bunları manuel olarak bağlamak MCP spesifikasyonunu yakından bilmeyi gerektiriyordu: ui:// URI’leri, özel mime türleri, araçlar ve kaynaklar arasında metadata koordinasyonu. Zor değil, ama zahmetli.

Üç Adımda Fluent API

Adım 1: Fonksiyonunuzu tanımlayın. Standart bir Azure Functions MCP aracı:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Adım 2: Bir MCP App’e yükseltin. Program başlatmanızda:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Adım 3: HTML görünümünüzü ekleyin. İhtiyacınız olan herhangi bir UI ile assets/hello-app.html dosyasını oluşturun.

Hepsi bu kadar. Fluent API tüm MCP spesifikasyon altyapısını halleder — sentetik kaynak fonksiyonu oluşturma, doğru mime türünü ayarlama, aracınızı görünümüne bağlayan metadata’yı ekleme.

API Yüzeyi İyi Tasarlanmış

Gerçekten beğendiğim birkaç şey:

Görünüm kaynakları esnektir. HTML’i diskteki dosyalardan sunabilir veya kendi kendine yetişen dağıtımlar için kaynakları doğrudan assembly’nize gömebilirsiniz:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP kompozisyona uygundur. Uygulamanızın ihtiyaç duyduğu kaynakları açıkça beyaz listeye alırsınız, en az ayrıcalık ilkelerini izleyerek. WithCsp‘yi birden fazla kez çağırın ve kaynaklar birikir:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Görünürlük kontrolü. Bir aracı yalnızca LLM’ye görünür, yalnızca host UI’a görünür veya her ikisine de görünür yapabilirsiniz. Yalnızca UI render eden ve model tarafından çağrılmaması gereken bir araç mı istiyorsunuz? Kolay:

.WithVisibility(McpVisibility.App) // Yalnızca UI, modelden gizli

Başlarken

Preview paketini ekleyin:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Zaten Azure Functions ile MCP araçları oluşturuyorsanız, bu yalnızca bir paket güncellemesi. Konsepte yeniyseniz MCP Apps hızlı başlangıç kılavuzu başlamak için en iyi yer.

Son Söz

MCP Apps, AI araçlama alanındaki daha heyecan verici gelişmelerden biri — yalnızca işler yapan değil, kullanıcılara şeyler gösterebilen araçlar. Fluent API protokol karmaşıklığını ortadan kaldırır ve önemli olan şeye odaklanmanızı sağlar: aracınızın mantığı ve UI’ı.

Tam API referansı ve örnekler için tam yazıyı okuyun.

C# 15 Union Türlerini Alıyor — ve Bunlar Tam İstediğimiz Şey

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Bunu bekliyordum. C# 15, union anahtar sözcüğünü tanıtıyor — derleyici tarafından zorunlu kılınan kapsamlı desen eşleştirmeli gerçek discriminated union’lar. F#‘ın discriminated union’larını ya da Rust’ın enum’larını hiç kıskandıysanız, bunun neden önemli olduğunu tam olarak biliyorsunuzdur.

Bill Wagner, .NET bloğunda konunun derinlemesine incelemesini yayımladı ve dürüst olmak gerekirse? Tasarım temiz, pratik ve son derece C# ruhuyla örtüşüyor. Gerçekte ne olduğunu ve neden ilk bakışta göründüğünden daha büyük bir mesele olduğunu size anlatayım.

Union türlerinin çözdüğü sorun

C# 15 öncesinde, bir metottan “birkaç olası türden biri” döndürmek her zaman bir uzlaşıydı:

object — kısıtlama yok, derleyici yardımı yok, her yerde savunmacı casting
İşaretçi arayüzler — daha iyi, ama herkes bunları uygulayabilir. Derleyici kümenin tamamlanmış olduğunu asla kabul edemez
Soyut taban sınıflar — aynı sorun, üstelik türlerin ortak bir atası olması gerekiyor

Bunların hiçbiri gerçekte istediğinizi vermiyor: derleyicinin her durumu ele aldığınızı garanti ettiği kapalı bir tür kümesi. Union türlerinin yaptığı tam olarak bu.

Sözdizimi güzelce basit

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Tek satır. Pet, bir Cat, bir Dog veya bir Bird tutabilir. Örtülü dönüşümler otomatik olarak oluşturulur:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Ve işte sihir — derleyici kapsamlı eşleştirmeyi zorunlu kılıyor:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

_ atma ifadesi gerekmiyor. Derleyici bu switch’in olası her durumu kapsadığını biliyor. Daha sonra union’a dördüncü bir tür eklerseniz, bunu ele almayan her switch ifadesi bir uyarı üretiyor. Eksik durumlar çalışma zamanında değil, derleme zamanında yakalanıyor.

Bu pratikte ne anlama geliyor

Pet örneği şirin, ama işte union’ların gerçek kodda asıl parladığı yer burası.

Farklı şekiller döndüren API yanıtları

public union ApiResult<T>(T, ApiError, ValidationFailure);

Artık her tüketici başarı, hata ve doğrulama başarısızlığını ele almak zorunda. “Hata durumunu kontrol etmeyi unuttum” hataları artık yok.

Tek değer veya koleksiyon

OneOrMore<T> deseni, union’ların yardımcı metotlarla nasıl bir gövdeye sahip olabileceğini gösteriyor:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Çağıranlar hangi form uygunsa onu kullanıyor:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

İlgisiz türleri birleştirme

Bu, geleneksel hiyerarşiler üzerindeki öldürücü özelliktir. Ortak atası olmayan türleri — string ve Exception, int ve IEnumerable<T> — union’layabilirsiniz.

Mevcut kütüphaneler için özel union’lar

İşte akıllı bir tasarım seçimi: [Union] özniteliğine sahip herhangi bir sınıf veya struct, temel deseni izlediği sürece (durum türleri için public constructor’lar ve bir Value özelliği) bir union türü olarak tanınır. OneOf gibi union benzeri türler zaten sağlayan kütüphaneler, iç yapılarını yeniden yazmadan derleyici desteğini benimseyebilir.

Değer türleriyle performans açısından kritik senaryolar için kütüphaneler, HasValue ve TryGetValue metotlarıyla boxing yapmayan erişim deseni uygulayabilir.

Büyük resim

Union türleri, C#‘a gelen daha kapsamlı bir bütünlük hikayesinin parçası:

Union türleri — kapalı bir tür kümesi üzerinde kapsamlı eşleştirme (şu an önizlemede mevcut)
Kapalı hiyerarşiler — closed değiştiricisi, tanımlayan derleme dışında türetilmiş sınıfları engelliyor (önerildi)
Kapalı enum’lar — bildirilmiş üyeler dışında değer oluşturulmasını engelliyor (önerildi)

Bu üç özellik birlikte, C#‘a herhangi bir ana akım dilde en kapsamlı tür güvenli desen eşleştirme sistemlerinden birini kazandıracak.

Bugün deneyin

Union türleri .NET 11 Preview 2’de mevcut:

.NET 11 Preview SDK‘yi yükleyin
Projenizde net11.0 hedefleyin
<LangVersion>preview</LangVersion> ayarlayın

Bir uyarı: Preview 2’de, henüz çalışma zamanında bulunmadıkları için UnionAttribute ve IUnion‘ı projenizde bildirmeniz gerekecek. Docs reposundan RuntimePolyfill.cs dosyasını alın veya şunu ekleyin:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Sonuç

Union türleri, nasıl bu olmadan idare ettiğimizi merak ettiren özelliklerden biri. Derleyici tarafından zorunlu kılınan kapsamlı eşleştirme, temiz sözdizimi, generic desteği ve mevcut desen eşleştirmeyle entegrasyon — C# yolunda yapılmış, istediğimiz her şey bu.

.NET 11 Preview 2’de deneyin, şeyleri kırın ve GitHub’da geri bildiriminizi paylaşın. Bu önizleme aşamasında ve C# ekibi aktif olarak dinliyor. Uç durumlarınız ve tasarım geri bildiriminiz nihai sürümü şekillendirecek.

Tam dil referansı için union türleri belgelerine ve özellik spesifikasyonuna bakın.

Aspire 13.2 Bir Dokümantasyon CLI'ı Sunuyor — ve AI Ajanınız da Kullanabilir

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Bir Aspire AppHost’un içinde derinlere dalıp entegrasyonları bağlarken Redis entegrasyonunun tam olarak hangi parametreleri beklediğini kontrol etmeniz gereken o anı biliyor musunuz? Tarayıcınıza geçersiniz, aspire.dev’de arama yaparsınız, API dokümanlarını incelersiniz, sonra editörünüze dönersiniz. Bağlam kaybolmuş. Akış bozulmuş.

Aspire 13.2 tam da bunun için bir çözüm sundu. aspire docs CLI’ı, terminali terk etmeden resmi Aspire belgelerini doğrudan arayıp okuyabilmenizi sağlıyor. Yeniden kullanılabilir servisler tarafından desteklendiği için, AI ajanları ve skill’ler de var olmayan API’ları uydurmak yerine belge aramak amacıyla aynı komutları kullanabiliyor.

Bu aslında ne sorunu çözüyor

David Pine orijinal yazısında konuyu net olarak özetliyor: AI ajanlar, geliştiricilere Aspire uygulamaları geliştirmede yardım etmekte berbattı. aspire run yerine dotnet run öneriyorlar, aspire.dev’deki belgeleri learn.microsoft.com’a yönlendiriyorlardı, güncel olmayan NuGet paketleri öneriyorlardı ve — kişisel favorim — var olmayan API’ları uyduruyorlardı.

Neden? Çünkü Aspire, çok dilli olmadan çok daha uzun süre .NET’e özel kaldı ve LLM’ler en son özelliklerin öncesindeki eğitim verileriyle çalışıyor. Bir AI ajanına mevcut belgeleri gerçekten arama yeteneği verdiğinizde, tahmin etmeyi bırakıp işe yarar hale geliyor.

Üç komut, sıfır tarayıcı sekmesi

CLI ferahlatıcı derecede basit:

Tüm belgeleri listele

aspire docs list

aspire.dev’de mevcut her belge sayfasını döndürür. Makine tarafından okunabilir çıktı mı istiyorsunuz? --format Json ekleyin.

Bir konu arayın

aspire docs search "redis"

Ağırlıklı ilgi puanlamasıyla hem başlıkları hem içeriği arar. Dahili olarak dokümantasyon araçlarını destekleyen arama motorunun aynısı. Başlıklar, slug’lar ve ilgi puanlarıyla sıralı sonuçlar alırsınız.

Tam sayfayı okuyun (ya da yalnızca bir bölümü)

aspire docs get redis-integration

Tam sayfayı markdown olarak terminalinize akıtır. Yalnızca bir bölüme mi ihtiyacınız var?

aspire docs get redis-integration --section "Add Redis resource"

Cerrahi hassasiyet. 500 satır kaydırma yok. Sadece ihtiyacınız olan kısım.

AI ajan boyutu

İşte AI araçlarıyla geliştirme yapan bizim için ilginç olan kısım. Aynı aspire docs komutları, AI ajanları için araç olarak çalışıyor — skill’ler, MCP sunucuları veya basit CLI sarmalayıcıları aracılığıyla.

AI asistanınızın eski eğitim verilerine dayalı Aspire API’ları uydurmak yerine, aspire docs search "postgres" çağırabilir, resmi entegrasyon belgelerini bulabilir, doğru sayfayı okuyabilir ve size belgelenmiş yaklaşımı sunabilir. Gerçek zamanlı, güncel belgeler — modelin altı ay önce ezberledikleri değil.

Bunun arkasındaki mimari kasıtlı. Aspire ekibi tek seferlik bir entegrasyon yerine yeniden kullanılabilir servisler (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) inşa etti. Bu, aynı arama motorunun terminaldeki insanlar, editörünüzdeki AI ajanları ve CI pipeline’ınızdaki otomasyonlar için çalışması anlamına geliyor.

Gerçek dünya senaryoları

Hızlı terminal aramaları: Üç dosya derindesiniz ve Redis yapılandırma parametrelerine ihtiyacınız var. İki komut, doksan saniye, işe geri dönüş:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI destekli geliştirme: VS Code skill’iniz CLI komutlarını sarmalıyor. “AppHost’uma bir PostgreSQL veritabanı ekle” diyorsunuz ve ajan cevap vermeden önce gerçek belgelere bakıyor. Halüsinasyon yok.

CI/CD doğrulama: Pipeline’ınız, AppHost yapılandırmalarını programatik olarak resmi belgelerle doğruluyor. --format Json çıktısı jq ve diğer araçlara temiz şekilde aktarılıyor.

Özel bilgi tabanları: Kendi AI araçlarınızı mı geliştiriyorsunuz? Yapılandırılmış JSON çıktısını doğrudan bilgi tabanınıza aktarın:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Web scraping yok. API anahtarı yok. Dokümantasyon araçlarının dahili olarak kullandığı aynı yapılandırılmış veri.

Belgeler her zaman canlı

En çok takdir ettiğim kısım bu. CLI bir anlık görüntü indirmiyor — aspire.dev’i ETag tabanlı önbelleklemeyle sorguluyor. Belgeler güncellenir güncellenmez, CLI’ınız ve üzerine inşa edilmiş tüm skill’ler bunu yansıtıyor. Eski kopyalar yok, “ama wiki şöyle diyordu…” anları yok.

Özet

aspire docs, gerçek bir sorunu temiz biçimde çözen küçük özelliklerden biri. İnsanlar terminale özgü belge erişimi kazanıyor. AI ajanları tahmin etmeyi bırakıp gerçek belgelere başvurmanın bir yolunu buluyor. Ve hepsi aynı gerçek kaynakla destekleniyor.

.NET Aspire ile geliştirme yapıyorsanız ve CLI’ı henüz denemediyseniz, aspire docs search "konunuz" çalıştırın ve nasıl hissettirdiğini görün. Sonra bu komutları kullandığınız AI skill veya otomasyon kurulumuna entegre etmeyi düşünün — ajanlarınız size teşekkür edecek.

Dokümantasyon araçlarının nasıl oluşturulduğuna dair David Pine’ın derinlemesine incelemesine ve tüm ayrıntılar için resmi CLI referansına göz atın.

Microsoft Agent Framework 1.0 Yayımlandı — .NET Geliştiricileri İçin Gerçekten Önemli Olan Şeyler

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Erken Semantic Kernel ve AutoGen günlerinden bu yana Agent Framework yolculuğunu takip ediyorsanız, bu gelişme önemli. Microsoft Agent Framework 1.0 sürümüne ulaştı — üretime hazır, kararlı API’lar, uzun vadeli destek taahhüdü. Hem .NET hem de Python için mevcut ve gerçek iş yükleri için gerçekten hazır.

Duyuru gürültüsünü bir kenara bırakarak, .NET ile AI destekli uygulamalar geliştiriyorsanız önemli olan şeylere odaklanayım.

Özet

Agent Framework 1.0, eski Semantic Kernel ve AutoGen’i tek, açık kaynaklı bir SDK’da birleştirir. Tek bir agent soyutlaması. Tek bir orkestrasyon motoru. Birden fazla AI sağlayıcısı. Kurumsal desenler için Semantic Kernel ile araştırma düzeyindeki çoklu-agent iş akışları için AutoGen arasında gidip geliyorsanız, buna son verebilirsiniz. Artık tek SDK bu.

Başlamak neredeyse haksız derecede kolay

İşte .NET’te çalışan bir agent:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Bu kadar. Birkaç satırla Azure Foundry üzerinde çalışan bir AI agentınız var. Python karşılığı da aynı derecede özlü. İlerlediğinizde function araçları, çok turlu konuşmalar ve streaming ekleyin — API yüzeyi tuhaflaşmadan büyür.

Çoklu-agent orkestrasyonu — işte asıl konu bu

Tek agentlar demolar için güzel, ama üretim senaryoları genellikle koordinasyon gerektirir. Agent Framework 1.0, Microsoft Research ve AutoGen’den gelen savaşta test edilmiş orkestrasyon desenlerini içerir:

Sequential (Sıralı) — agentlar sırayla işler (yazar → gözden geçiren → editör)
Concurrent (Eş zamanlı) — birden fazla agenta paralel olarak yayıl, sonuçları birleştir
Handoff (Devir teslim) — bir agent, niyete göre başka birine devreder
Group chat (Grup sohbeti) — birden fazla agent tartışır ve bir çözümde uzlaşır
Magentic-One — MSR’den araştırma düzeyindeki çoklu-agent deseni

Tümü streaming, checkpointing, human-in-the-loop onayları ve duraklat/devam et özelliklerini destekler. Checkpointing kısmı kritik — uzun süreli iş akışları süreç yeniden başlatmalarını atlatır. Azure Functions ile dayanıklı iş akışları geliştirmiş .NET geliştiricileri için bu tanıdık hissettiriyor.

En önemli özellikler

Bilmeye değer şeylerin kısa listesi:

Middleware kancaları. ASP.NET Core’un middleware pipeline’ları var ya? Aynı kavram, ama agent yürütmesi için. Her aşamayı yakalayın — içerik güvenliği, loglama, uyumluluk politikaları ekleyin — agent prompt’larına dokunmadan. Agentları kurumsal düzeyde hazır kılmanın yolu budur.

Takılabilir bellek. Konuşma geçmişi, kalıcı anahtar-değer durumu, vektör tabanlı erişim. Backend’inizi seçin: Foundry Agent Service, Mem0, Redis, Neo4j veya kendinizinkini yazın. Bellek, durumsuz bir LLM çağrısını gerçekten bağlamı hatırlayan bir agenta dönüştüren şeydir.

Bildirimsel YAML agentları. Agentınızın talimatlarını, araçlarını, belleğini ve orkestrasyon topolojisini sürüm kontrollü YAML dosyalarında tanımlayın. Tek bir API çağrısıyla yükleyin ve çalıştırın. Bu, kod yeniden dağıtmadan agent davranışını yinelemek isteyen ekipler için oyun değiştiricidir.

A2A ve MCP desteği. MCP (Model Context Protocol), agentların harici araçları dinamik olarak keşfetmesine ve çağırmasına izin verir. A2A (Agent-to-Agent protokolü), çalışma zamanları arası işbirliğini mümkün kılar — .NET agentlarınız diğer framework’lerde çalışan agentlarla koordinasyon kurabilir. A2A 1.0 desteği yakında geliyor.

Takip etmeye değer önizleme özellikleri

Bazı özellikler 1.0’da önizleme olarak yayımlandı — işlevsel ama API’lar gelişebilir:

DevUI — agent yürütmesini, mesaj akışlarını ve araç çağrılarını gerçek zamanlı olarak görselleştirmek için tarayıcı tabanlı yerel hata ayıklayıcı. Application Insights gibi ama agent muhakemesi için.
GitHub Copilot SDK ve Claude Code SDK — Copilot veya Claude’u doğrudan orkestrasyon kodunuzdan agent harness’i olarak kullanın. Kod yazabilen bir agentı aynı iş akışındaki diğer agentlarla birleştirin.
Agent Harness — agentlara shell, dosya sistemi ve mesajlaşma döngülerine erişim sağlayan özelleştirilebilir yerel çalışma zamanı. Kodlama agentları ve otomasyon desenlerini düşünün.
Skills — agentlara kullanıma hazır yapılandırılmış yetenekler sunan yeniden kullanılabilir alan yetkinliği paketleri.

Semantic Kernel veya AutoGen’den geçiş

Mevcut Semantic Kernel veya AutoGen kodunuz varsa, kodunuzu analiz eden ve adım adım geçiş planları üreten özel geçiş asistanları mevcuttur. Semantic Kernel geçiş rehberi ve AutoGen geçiş rehberi her şeyi adım adım anlatıyor.

RC paketlerindeyseniz, 1.0’a yükseltme sadece bir sürüm güncellemesidir.

Sonuç

Agent Framework 1.0, kurumsal ekiplerin beklediği üretim mihenk taşıdır. Kararlı API’lar, çoklu sağlayıcı desteği, gerçek ölçekte çalışan orkestrasyon desenleri ve hem Semantic Kernel hem de AutoGen’den geçiş yolları.

Framework GitHub’da tamamen açık kaynak ve dotnet add package Microsoft.Agents.AI ile bugün başlayabilirsiniz. Ellerinizi kirletmek için hızlı başlangıç rehberine ve örneklere göz atın.

“Üretimde kullanmak güvenli” sinyalini bekliyorsanız — işte bu.

Aspire 13.2 Dashboard'una Telemetri API'si Geldi — ve Her Şeyi Değiştiriyor

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

.NET Aspire ile dağıtık uygulamalar geliştiriyorsanız, dashboard’un tüm deneyimin en iyi parçası olduğunu zaten bilirsiniz. Tüm izleriniz, loglarınız ve metrikleriniz tek bir yerde — harici Jaeger yok, Seq kurulumu yok, “öbür terminale bakayım” anı yok.

Aspire 13.2 bunu önemli ölçüde daha iyi hale getirdi. James Newton-King güncellemeyi duyurdu ve dürüst olmak gerekirse? Telemetri dışa aktarma ve API özellikleri tek başına yükseltmeye değer.

Telemetriyi sağlıklı bir şekilde dışa aktarın

Hepimizin yaşadığı senaryoyu düşünün: dağıtık bir sorunu ayıklıyorsunuz, yirmi dakikalık kurulumun ardından sonunda yeniden üretiyorsunuz ve şimdi yaşananları ekibinizle paylaşmanız gerekiyor. Önceden? Ekran görüntüleri. İz ID’lerini kopyala-yapıştır. Her zamanki karmaşa.

Aspire 13.2, şunları yapabileceğiniz uygun bir Logları ve telemetriyi yönet iletişim kutusu ekliyor:

Tüm telemetriyi temizleme (yeniden üretim denemesinden önce kullanışlı)
Seçili telemetriyi standart OTLP/JSON formatında ZIP dosyasına dışa aktarma
Bu ZIP’i daha sonra herhangi bir Aspire dashboard’una yeniden içe aktarma

Son kısım öldürücü özellik. Bir hatayı yeniden üretirsiniz, telemetriyi dışa aktarırsınız, iş öğenize eklersiniz ve ekip arkadaşınız tam olarak gördüğünüzü görmek için kendi dashboard’una içe aktarabilir. Artık “kendi makinende yeniden üretebilir misin?” yok.

Bireysel izler, span’lar ve loglar da bağlam menülerinde “JSON Dışa Aktar” seçeneği kazanıyor. Tek bir izi paylaşmanız mı gerekiyor? Sağ tıklayın, JSON kopyalayın, PR açıklamanıza yapıştırın. Tamam.

Telemetri API’si gerçek oyun değiştirici

En çok bu konuya heyecanlıyım. Dashboard artık telemetri verilerini programatik olarak sorgulamak için /api/telemetry altında bir HTTP API sunuyor. Kullanılabilir endpoint’ler:

GET /api/telemetry/resources — telemetrisi olan kaynakları listele
GET /api/telemetry/spans — filtrelerle span’ları sorgula
GET /api/telemetry/logs — filtrelerle logları sorgula
GET /api/telemetry/traces — izleri listele
GET /api/telemetry/traces/{traceId} — belirli bir iz için tüm span’ları getir

Her şey OTLP JSON formatında dönüyor. Bu, yeni aspire agent mcp ve aspire otel CLI komutlarını besliyor, ama gerçek anlam daha büyük: artık uygulamanızın telemetrisini doğrudan sorgulayan araçlar, scriptler ve AI agent entegrasyonları oluşturabilirsiniz.

Hata ayıklarken gerçek dağıtık izlerinize bakabilen bir AI kodlama agentı hayal edin. Bu artık hayali değil — bu API’nin mümkün kıldığı şey tam olarak bu.

GenAI telemetri pratikleşiyor

Semantic Kernel veya Microsoft.Extensions.AI ile AI destekli uygulamalar geliştiriyorsanız, geliştirilmiş GenAI telemetri görselleştiricisini takdir edeceksiniz. Aspire 13.2 şunları ekliyor:

Markdown olarak render edilen AI araç açıklamaları
AI iz erişimini hızlandırmak için izler sayfasında özel GenAI butonu
Kesik veya standart olmayan GenAI JSON için daha iyi hata yönetimi
Araç tanımları arasında tıkla-vurgula navigasyonu

Blog yazısı, VS Code Copilot chat, Copilot CLI ve OpenCode’un tümünün OTEL_EXPORTER_OTLP_ENDPOINT yapılandırmasını desteklediğinden bahsediyor. Bunları Aspire dashboard’una yönlendirin ve AI agentlarınızın telemetri aracılığıyla gerçek zamanlı olarak nasıl düşündüğünü izleyebilirsiniz. Bu, başka hiçbir yerde bulamayacağınız bir hata ayıklama deneyimidir.

Sonuç

Aspire 13.2, dashboard’u “güzel bir hata ayıklama arayüzü"nden “programlanabilir bir gözlemlenebilirlik platformu"na taşıyor. Dışa aktarma/içe aktarma iş akışı tek başına dağıtık hata ayıklamada gerçek zaman kazandırıyor; telemetri API’si ise AI destekli tanılama kapısını açıyor.

Zaten Aspire kullanıyorsanız, yükseltin. Kullanmıyorsanız — bu, aspire.dev’e göz atmak ve tüm meseleyi anlamak için iyi bir neden.

azd Artık AI Ajanlarınızı Yerel Ortamda Çalıştırıp Hata Ayıklamanıza İzin Veriyor — Mart 2026'daki Değişiklikler

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Bir ayda yedi sürüm. Azure Developer CLI (azd) ekibinin Mart 2026’da yaptığı bu ve başlık özelliği benim beklediğim şey: AI ajanları için yerel çalıştırma ve hata ayıklama döngüsü.

PC Chan tam özeti yayımladı ve orada pek çok şey olsa da, AI destekli uygulamalar geliştiren .NET geliştiricileri için gerçekten önem taşıyan şeyleri özetleyeyim.

AI ajanlarını dağıtmadan çalıştırın ve hata ayıklayın

En büyük yenilik bu. Yeni azure.ai.agents uzantısı, AI ajanları için düzgün bir iç döngü deneyimi sunan bir dizi komut ekliyor:

azd ai agent run — ajanı yerel olarak başlatır
azd ai agent invoke — ona mesaj gönderir (yerel veya dağıtılmış)
azd ai agent show — container durumunu ve sağlığını gösterir
azd ai agent monitor — container loglarını gerçek zamanlı akıtır

Bundan önce, bir AI ajanını test etmek her değişiklik yaptığınızda Microsoft Foundry’e dağıtmak anlamına geliyordu. Artık yerel olarak yineleyebilir, ajanın davranışını test edebilir ve yalnızca hazır olduğunuzda dağıtabilirsiniz. Microsoft Agent Framework veya Semantic Kernel ile ajan geliştiriyorsanız, bu günlük iş akışınızı değiştiriyor.

invoke komutu hem yerel hem de dağıtılmış ajanlara karşı çalışıyor; bu, ajanın nerede çalıştığından bağımsız olarak aynı test iş akışını kullanabileceğiniz anlamına geliyor. Bu tür bir ayrıntı, iki ayrı test betiği setini sürdürmek zorunda kalmaktan sizi kurtarıyor.

GitHub Copilot azd projenizi iskelet oluşturuyor

azd init artık “GitHub Copilot ile Kur (Önizleme)” seçeneği sunuyor. Proje yapınız hakkındaki prompt’lara manuel olarak yanıt vermek yerine, bir Copilot ajanı yapılandırmayı sizin için iskelet oluşturuyor. Herhangi bir şeyi değiştirmeden önce kirli çalışma dizinini kontrol ediyor ve MCP sunucusu araç iznini önceden istiyor.

Bir komut başarısız olduğunda, azd artık AI destekli sorun giderme sunuyor: bir kategori seçin (açıkla, rehberlik, sorun gider veya atla), ajanın bir düzeltme önermesine izin verin ve yeniden deneyin — hepsi terminali terk etmeden. Karmaşık altyapı kurulumları için bu gerçek anlamda zaman kazandırıyor.

Container App Jobs ve dağıtım iyileştirmeleri

Dikkat çekmeye değer birkaç dağıtım özelliği:

Container App Jobs: azd artık mevcut host: containerapp yapılandırması aracılığıyla Microsoft.App/jobs dağıtıyor. Bicep şablonunuz hedefin Container App mı yoksa Job mu olduğunu belirliyor — ekstra kurulum gerekmez.
Yapılandırılabilir dağıtım zaman aşımları: azd deploy üzerinde yeni --timeout bayrağı ve azure.yaml‘da deployTimeout alanı. Varsayılan 1200 saniyelik sınırı artık tahmin etmek zorunda değilsiniz.
Uzak derleme yedeklemesi: Uzak ACR derlemesi başarısız olduğunda, azd otomatik olarak yerel Docker/Podman derlemesine geri düşüyor.
Yerel ön uçuş doğrulama: Bicep parametreleri, Azure’a bir gidiş-dönüş yapmadan eksik parametreleri yakalamak için dağıtımdan önce yerel olarak doğrulanıyor.

Geliştirici deneyimi iyileştirmeleri

Toplanınca fark yaratan küçük iyileştirmeler:

JS/TS projeleri için otomatik pnpm/yarn algılama
Python paketleme için pyproject.toml desteği
Yerel şablon dizinleri — azd init --template artık çevrimdışı yineleme için dosya sistemi yollarını kabul ediyor
--no-prompt modunda daha iyi hata mesajları — eksik tüm değerler çözüm komutlarıyla birlikte bir kerede raporlanıyor
Derleme ortam değişkenleri tüm framework derleme alt süreçlerine enjekte ediliyor (.NET, Node.js, Java, Python)

Son madde ince ama önemli: .NET derlemeniz artık azd ortam değişkenlerine erişebilir; bu, ekstra betik yazmadan derleme zamanı yapılandırma enjeksiyonu yapabileceğiniz anlamına geliyor.

Özet

Yerel AI ajan hata ayıklama döngüsü bu sürümün yıldızı, ancak dağıtım iyileştirmeleri ve geliştirici deneyimi cilasının birikmesi azd‘yi her zamankinden daha olgun hissettiriyor. .NET uygulamalarını Azure’a — özellikle AI ajanlarını — dağıtıyorsanız, bu güncelleme kuruluma değer.

Her ayrıntı için tam sürüm notlarına bakın ya da azd kurulumu ile başlayın.

Visual Studio'nun Mart Güncellemesiyle Özel Copilot Agentları Oluşturabilirsiniz — find_symbol Aracı Gerçekten Büyük

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio bugüne kadarki en önemli Copilot güncellemesini aldı. Mark Downie Mart sürümünü duyurdu ve başlık özel agentlar — ama dürüstçe söylemek gerekirse, daha aşağılarda geçen find_symbol aracı iş akışınızı en çok değiştirecek özellik olabilir.

Gerçekte neler olduğunu açıklayayım.

Reponuzda özel Copilot agentları

Copilot’un ekibinizin kodlama standartlarını izlemesini, build pipeline’ınızı çalıştırmasını veya dahili belgelerinizi sorgulamasını ister misiniz? Artık tam olarak bunu oluşturabilirsiniz.

Özel agentlar, reponuzdaki .github/agents/ klasörüne bıraktığınız .agent.md dosyaları olarak tanımlanıyor. Her agent, çalışma alanı farkındalığına, kod anlayışına, araçlara, tercih ettiğiniz modele ve harici servislere MCP bağlantılarına tam erişim elde ediyor. Yerleşik agentların yanında agent seçicisinde görünüyorlar.

Bu, VS Code’un süredir desteklediği desenin aynısı — ve Visual Studio’nun yetişmesini görmek harika. VS Code için zaten agent oluşturmuş ekipler için .agent.md dosyalarınız her iki IDE’de de çalışmalı (ancak araç adları farklılık gösterebilir, bu yüzden test edin).

awesome-copilot reposunda başlangıç noktası olarak kullanabileceğiniz topluluk katkılı agent yapılandırmaları var.

Agent becerileri: yeniden kullanılabilir talimat paketleri

Beceriler, reponuzdaki .github/skills/ klasöründen veya profilinizdeki ~/.copilot/skills/ konumundan otomatik olarak alınıyor. Her beceri, Agent Skills spesifikasyonunu takip eden bir SKILL.md dosyası.

Becerileri, karıştırıp eşleştirebileceğiniz modüler uzmanlık alanları olarak düşünün. API kurallarınız için bir beceri, test desenleriniz için bir diğeri ve dağıtım iş akışınız için başka biri olabilir. Bir beceri etkinleştiğinde, uygulandığını bilmeniz için sohbette görünüyor.

VS Code’da beceri kullandıysanız Visual Studio’da da aynı şekilde çalışıyorlar.

find_symbol: agentlar için dile duyarlı navigasyon

İşler burada gerçekten ilginçleşiyor. Yeni find_symbol aracı, Copilot’un agent moduna gerçek dil servisi destekli sembol navigasyonu sağlıyor. Kodunuzu metin olarak aramak yerine agent şunları yapabiliyor:

Projeniz genelinde bir sembole yapılan tüm referansları bul
Tür bilgisine, bildirimlere ve kapsam meta verilerine eriş
Tam dil farkındalığıyla çağrı noktalarında gezin

Pratikte ne anlama geliyor: Copilot’tan bir metodu yeniden düzenlemesini veya çağrı noktaları genelinde parametre imzasını güncellemesini istediğinizde, kodunuzun yapısını gerçekten görebiliyor. Artık “agent metodu değiştirdi ama üç çağrı noktasını kaçırdı” durumu yok.

Desteklenen diller arasında C#, C++, Razor, TypeScript ve desteklenen LSP uzantısına sahip her şey yer alıyor. .NET geliştiricileri için bu büyük bir iyileştirme — derin tür hiyerarşileri ve arayüzlere sahip C# kod tabanları, sembol farkındalıklı navigasyondan büyük ölçüde yararlanıyor.

Copilot ile testleri profilleyin

Test Gezgini bağlam menüsünde artık bir Profile with Copilot komutu var. Bir test seçin, profile tıklayın ve Profiling Agent onu otomatik olarak çalıştırıp performansı analiz eder — uygulanabilir içgörüler sunmak için CPU kullanımı ve enstrümantasyon verilerini birleştirir.

Artık profil oluşturucu oturumlarını manuel olarak yapılandırmak, testi çalıştırmak, sonuçları dışa aktarmak ve bir flame graph okumaya çalışmak yok. Agent analizi yapıp neyin yavaş olduğunu ve neden olduğunu söylüyor. Şu anda yalnızca .NET, ki bu Visual Studio’nun derin .NET tanı entegrasyonu göz önüne alındığında mantıklı.

Canlı hata ayıklama sırasında performans ipuçları

Performans optimizasyonu artık sonrasında değil, hata ayıklarken gerçekleşiyor. Kod üzerinde adım adım ilerlerken Visual Studio satır içinde yürütme süresini ve performans sinyallerini gösteriyor. Yavaş bir satır mı gördünüz? Perf İpucu’na tıklayın ve Copilot’tan hemen orada optimizasyon önerileri isteyin.

Profiling Agent çalışma zamanı verilerini otomatik olarak yakalıyor — geçen süre, CPU kullanımı, bellek davranışı — ve Copilot bunu sıcak noktaları tespit etmek için kullanıyor. Bu, performans çalışmasını ertelediğiniz ayrı bir görev yerine hata ayıklama akışınızın bir parçası olarak tutuyor.

Solution Explorer’dan NuGet güvenlik açıklarını düzeltin

Bir NuGet paketinde güvenlik açığı tespit edildiğinde, artık doğrudan Solution Explorer’da Fix with GitHub Copilot bağlantısıyla bir bildirim görüyorsunuz. Tıklayın ve Copilot güvenlik açığını analiz eder, doğru paket güncellemelerini önerir ve uygular.

Bağımlılıkları güncel tutmakta zorlanan ekipler için (ki bu esasen herkes), “bir güvenlik açığı olduğunu biliyorum ama doğru güncelleme yolunu bulmak başlı başına bir proje” sürtünmesini ortadan kaldırıyor.

Sonuç

Özel agentlar ve beceriler başlık haberi, ancak find_symbol uyuyan dev — .NET kodunu yeniden düzenlerken Copilot’un ne kadar doğru olabileceğini temelden değiştiriyor. Canlı profil oluşturma entegrasyonu ve güvenlik açığı düzeltmeleriyle birleşince bu güncelleme, Visual Studio’nun AI özelliklerini demo hazır değil gerçekten pratik hissettiriyor.

Her şeyi denemek için Visual Studio 2026 Insiders‘ı indirin.

KubeCon Avrupa 2026: .NET Geliştiricilerinin Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Büyük bir duyuru yazısı yayımlandığında ve “harika, ama bu benim için ne değiştiriyor ki” diye düşünerek kaydırma yaptığınız o hissi bilirsiniz, değil mi? Ben her KubeCon sezonunda böyle hissediyorum.

Microsoft, KubeCon Avrupa 2026 tam özetini yayımladı — bizzat Brendan Burns tarafından yazıldı — ve dürüst olmak gerekirse? Burada gerçek bir içerik var. Yalnızca özellik onay kutuları değil, üretimdeki çalışma biçiminizi değiştiren türden operasyonel iyileştirmeler.

.NET geliştiricileri olarak bizim için gerçekten önemli olanları ele alayım.

Service Mesh Yükü Olmadan mTLS

Service mesh’ler hakkında şunu söylemek gerekir: herkes güvenlik garantilerini istiyor, kimse operasyonel yükü istemiyor. AKS nihayet bu boşluğu kapatıyor.

Azure Kubernetes Application Network, ağır sidecar’lı bir mesh dağıtmadan karşılıklı TLS, uygulama farkında yetkilendirme ve trafik telemetrisi sunuyor. Advanced Container Networking Services’deki Cilium mTLS ile birleşince, kimlik yönetimi için X.509 sertifikaları ve SPIRE kullanan şifreli pod-to-pod iletişimi elde ediyorsunuz.

Pratikte ne anlama geliyor: arka plan worker’larıyla konuşan ASP.NET Core API’leriniz, birbirini çağıran gRPC servisleriniz — sıfır uygulama kodu değişikliğiyle ağ düzeyinde şifreli ve kimlik doğrulamalı. Bu büyük bir şey.

ingress-nginx‘ten geçiş yapan ekipler için tam Kubernetes Gateway API desteğiyle Application Routing with Meshless Istio da mevcut. Sidecar yok. Standart tabanlı. Ve kademeli geçiş için ingress2gateway araçlarını gönderdiler.

Sonradan Düşünülmemiş GPU Gözlemlenebilirliği

.NET servislerinizin yanında AI çıkarımı çalıştırıyorsanız (ve dürüst olalım, kim başlamıyor?), GPU izleme kör noktasına çarpmış olabilirsiniz. Harika CPU/bellek dashboard’larınız olur ve ardından… manuel exporter bağlantıları olmadan GPU’lar için hiçbir şey.

AKS artık GPU metriklerini yönetilen Prometheus ve Grafana’ya yerel olarak sunuyor. Aynı yığın, aynı dashboard’lar, aynı uyarı pipeline’ı. Özel exporter yok, üçüncü taraf ajan yok.

Ağ tarafında, tek tıklamalı Azure Monitor deneyimiyle HTTP, gRPC ve Kafka trafiği için akış başına görünürlük eklediler. IP’ler, portlar, iş yükleri, akış yönü, politika kararları — hepsi yerleşik dashboard’larda.

Ve beni iki kez baktıran şu oldu: agentic container networking kümenizin ağ durumu hakkında doğal dil soruları sorabileceğiniz bir web UI ekliyor. “Pod X neden servis Y’ye ulaşamıyor?” → canlı telemetriden salt okunur tanılamalar. Gece 2’de gerçekten kullanışlı.

PhD Gerektirmeyen Kümeler Arası Ağ

Multi-cluster Kubernetes, tarihsel olarak “kendi ağ yapıştırıcınızı getirin” deneyimiydi. Azure Kubernetes Fleet Manager artık yönetilen Cilium cluster mesh üzerinden kümeler arası ağ sunuyor:

AKS kümeleri arasında birleşik bağlantı
Kümeler arası keşif için global servis kaydı
Merkezi olarak yönetilen, küme başına tekrarlanmayan konfigürasyon

Dayanıklılık veya uyumluluk için bölgeler arasında .NET mikro servisler çalıştırıyorsanız, bu çok sayıda kırılgan özel yapıştırıcının yerini alıyor. West Europe’daki A Servisi, tutarlı yönlendirme ve güvenlik politikalarıyla mesh üzerinden East US’deki B Servisini keşfedebilir ve çağırabilir.

Cesaret Gerektirmeyen Yükseltmeler

Dürüst olalım — üretimdeki Kubernetes yükseltmeleri streslidir. “Yükselt ve umut et” pek çok ekip için fiili strateji olmuştur ve kümelerin sürümlerin gerisinde kalmasının ana nedenidir.

İki yeni özellik bunu değiştiriyor:

Mavi-yeşil agent pool yükseltmeleri yeni konfigürasyonla paralel bir node pool oluşturur. Davranışı doğrulayın, trafiği kademeli olarak kaydırın ve temiz bir geri alma yolu tutun. Üretim node’larında artık yerinde mutasyon yok.

Agent pool rollback, bir yükseltme ters gittiğinde kümeyi yeniden oluşturmadan bir node pool’u önceki Kubernetes sürümüne ve node imajına döndürmenizi sağlar.

Birlikte ele alındığında, bunlar nihayet operatörlere yükseltme yaşam döngüsü üzerinde gerçek kontrol veriyor. .NET ekipleri için bu önemlidir çünkü platform hızı, yeni runtime’ları, güvenlik yamalarını ve ağ özelliklerini ne kadar hızlı benimseyebileceğinizi doğrudan belirler.

AI İş Yükleri Birinci Sınıf Kubernetes Vatandaşı Oluyor

Upstream açık kaynak çalışması da eşit derecede önemli. Dynamic Resource Allocation (DRA) Kubernetes 1.36’da GA’ya geçti, GPU planlamasını bir geçici çözüm yerine gerçek anlamda birinci sınıf bir özellik haline getirdi.

İzlemeye değer birkaç proje:

Proje	Ne Yapıyor
AI Runway	Çıkarım için ortak Kubernetes API’si — K8s bilmeden model dağıtın, HuggingFace keşfi ve maliyet tahminleriyle
HolmesGPT	Cloud-native için agentic sorun giderme — artık CNCF Sandbox projesi
Dalec	SBOM üretimiyle bildirimsel container imaj oluşturma — derleme aşamasında daha az CVE

Yön açık: .NET API’niz, Semantic Kernel orkestrasyon katmanınız ve çıkarım iş yüklerinizin hepsi tek tutarlı bir platform modelinde çalışmalı. Oraya doğru ilerliyoruz.

Bu Hafta Nereden Başlardım

Bu değişiklikleri ekibiniz için değerlendiriyorsanız, işte dürüst öncelik listem:

Önce gözlemlenebilirlik — üretim dışı bir kümede GPU metriklerini ve ağ akış günlüklerini etkinleştirin. Neyi kaçırdığınızı görün.
Mavi-yeşil yükseltmeleri deneyin — bir sonraki üretim kümesi yükseltmenizden önce rollback iş akışını test edin. Sürece güven inşa edin.
Kimlik farkında ağı pilot edin — bir dahili servis yolu seçin ve Cilium ile mTLS’i etkinleştirin. Yükü ölçün (spoiler: minimumdur).
Fleet Manager’ı değerlendirin — ikiden fazla küme çalıştırıyorsanız, kümeler arası ağ azaltılan özel yapıştırıcıyla kendini amorti eder.

Küçük deneyler, hızlı geri bildirim. Her zaman doğru hamle budur.

Son Söz

KubeCon duyuruları bunaltıcı olabiliyor, ancak bu grup gerçekten AKS’teki .NET ekipleri için iğneyi hareket ettiriyor. Mesh yükü olmadan daha iyi ağ güvenliği, gerçek GPU gözlemlenebilirliği, daha güvenli yükseltmeler ve daha güçlü AI altyapısı temelleri.

Halihazırda AKS’teyseniz, bu operasyonel temelinizi sıkılaştırmak için harika bir an. .NET iş yüklerini Kubernetes’e taşımayı planlıyorsanız — platform önemli ölçüde daha üretim hazır hale geldi.

.NET Geliştiricilerinin VS Code 1.112'de Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 yayınlandı ve dürüstçe söylemek gerekirse? .NET dünyasında gününüzü geçiriyorsanız bu sürüm farklı bir his veriyor. Resmi sürüm notlarında pek çok şey var, ama sizi biraz kaydırmadan kurtarayım ve gerçekten bizim için önemli olanlara odaklanayım.

Copilot CLI çok daha kullanışlı hale geldi

Bu sürümün büyük teması agent özerkliği — Copilot’a her adımı siz denetlemeden işini yapması için daha fazla alan tanıma.

Mesaj yönlendirme ve sıralama

Copilot CLI bir görevin ortasındayken bir şeyi söylemeyi unuttuğunuzu fark ettiğiniz o anı bilirsiniz. Önce beklemeniz gerekiyordu. Artık bir istek hâlâ çalışırken mesaj gönderebilirsiniz — ya mevcut yanıtı yönlendirmek ya da takip talimatlarını sıraya almak için.

Bu, Copilot’un bir proje kurduğunu izlerken “ah, buna MassTransit de eklemeliyim” dediğiniz uzun dotnet iskele görevleri için çok önemli.

İzin seviyeleri

En çok heyecanlandığım bu. Copilot CLI oturumları artık üç izin seviyesini destekliyor:

Default Permissions — araçların çalışmadan önce onay istediği olağan akış
Bypass Approvals — her şeyi otomatik onaylar ve hatalarda yeniden dener
Autopilot — tamamen özerk: araçları onaylar, kendi sorularını yanıtlar ve görev tamamlanana kadar devam eder

Entity Framework ile migrasyonlar, Docker kurulumu ve yeni bir ASP.NET Core API’si oluşturuyorsanız — Autopilot modu demek istediğinizi tanımlayıp kahve almaya gidebilirsiniz demek. Gerisini halledecek.

Autopilot’u chat.autopilot.enabled ayarıyla etkinleştirebilirsiniz.

Devretmeden önce değişiklikleri önizleyin

Copilot CLI’a bir görev devrettiğinizde bir worktree oluşturur. Daha önce, teslim edilmemiş değişiklikleriniz varsa nelerin etkileneceğini görmek için Source Control’ü kontrol etmeniz gerekiyordu. Artık Chat görünümü, kopyalamak, taşımak veya yoksaymak isteyip istemediğinize karar vermeden önce bekleyen değişiklikleri doğrudan orada gösteriyor.

Küçük bir şey, ama “dur, ne hazırlamıştım?” anından kurtarıyor.

VS Code’dan çıkmadan web uygulamalarını hata ayıklayın

Entegre tarayıcı artık tam hata ayıklamayı destekliyor. Kesme noktaları koyabilir, kod üzerinde adım adım ilerleyebilir ve değişkenleri inceleyebilirsiniz — hepsi VS Code içinde. Artık Edge DevTools’a geçiş yok.

Yeni bir editor-browser hata ayıklama türü var ve mevcut msedge veya chrome başlatma yapılandırmalarınız varsa, geçiş launch.json‘daki type alanını değiştirmek kadar basit:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor geliştiricileri için bu oyun değiştirici. Terminalde zaten dotnet watch çalıştırıyorsunuz — artık hata ayıklamanız da aynı pencerede kalıyor.

Tarayıcı aynı zamanda bağımsız yakınlaştırma seviyeleri (sonunda!), düzgün sağ tıklama bağlam menüleri aldı ve yakınlaştırma web sitesi başına hatırlanıyor.

MCP sunucu korumalı alanı

Bu, düşündüğünüzden daha önemli. MCP sunucuları kullanıyorsanız — belki Azure kaynaklarınız veya veritabanı sorguları için özel bir tane kurduysanız — bunlar VS Code sürecinizle aynı izinlerle çalışıyordu. Yani dosya sisteminize, ağınıza, her şeye tam erişim.

Artık onları korumalı alana alabilirsiniz. mcp.json dosyanızda:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Korumalı alandaki bir sunucu sahip olmadığı bir şeye erişim gerektirdiğinde, VS Code izin vermeniz için sizi uyarıyor. “Kimse garip bir şey yapmasın” yaklaşımından çok daha iyi.

Monorepo özelleştirme keşfi

Bir monorepo’da çalışıyorsanız (ve dürüstçe söylemek gerekirse, pek çok kurumsal .NET çözümü buna dönüşüyor), bu gerçek bir sorun noktasını çözüyor.

Daha önce, reponuzun bir alt klasörünü açtığınızda VS Code, depo kökünüzdeki copilot-instructions.md, AGENTS.md veya özel becerileri bulamıyordu. Artık chat.useCustomizationsInParentRepositories ayarıyla .git köküne kadar yukarı çıkıp her şeyi buluyor.

Bu, ekibinizin tüm monorepo projelerine herkesin kök klasörü açmasına gerek kalmadan agent talimatlarını, prompt dosyalarını ve özel araçları paylaşabilmesi anlamına geliyor.

Agent hata ayıklama için /troubleshoot

Özel talimatlar veya beceriler ayarlayıp neden alınmadığını hiç merak ettiniz mi? Yeni /troubleshoot becerisi agent hata ayıklama günlüklerini okuyup ne olduğunu söylüyor — hangi araçların kullanıldığı veya atlandığı, neden talimatların yüklenmediği ve yavaş yanıtlara neyin yol açtığı.

Bunu şununla etkinleştirin:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Ardından sohbette /troubleshoot neden özel beceri yüklenmiyor? yazın.

Bu hata ayıklama günlüklerini artık dışa ve içe aktarabilirsiniz; bir şey beklendiği gibi çalışmadığında ekibinizle paylaşmak için harika.

Resim ve ikili dosya desteği

Agentlar artık diskten resim dosyalarını ve ikili dosyaları doğrudan okuyabiliyor. İkili dosyalar hexdump formatında sunuluyor ve resim çıktıları (entegre tarayıcıdan alınan ekran görüntüleri gibi) bir carousel görünümünde gösteriliyor.

.NET geliştiricileri için düşünün: bir UI hatasının ekran görüntüsünü sohbete yapıştırın ve agent neyin yanlış olduğunu anlasın, ya da Blazor bileşeni render çıktısını analiz ettirin.

Otomatik sembol referansları

Küçük bir yaşam kalitesi iyileştirmesi: bir sembol adını (bir sınıf, metot vb.) kopyalayıp sohbete yapıştırdığınızda VS Code artık otomatik olarak #sym:İsim referansına dönüştürüyor. Bu, agent’a manuel olarak eklemek zorunda kalmadan bu sembol hakkında tam bağlam sağlıyor.

Bunun yerine düz metin istiyorsanız Ctrl+Shift+V kullanın.

Eklentiler artık etkinleştirilebilir/devre dışı bırakılabilir

Daha önce bir MCP sunucusunu veya eklentiyi devre dışı bırakmak kaldırmak anlamına geliyordu. Artık hem genel hem de çalışma alanı başına açıp kapatabilirsiniz. Extensions görünümünde veya Customizations görünümünde sağ tıklayın ve işiniz bitti.

npm ve pypi’den eklentiler artık otomatik güncellenebilir; ancak güncellemeler makinenizde yeni kod çalıştırmak anlamına geldiğinden önce onay isteyecekler.

Sonuç

VS Code 1.112, agent deneyimini açıkça ileriye taşıyor — daha fazla özerklik, daha iyi hata ayıklama, daha sıkı güvenlik. .NET geliştiricileri için entegre tarayıcı hata ayıklama ve Copilot CLI iyileştirmeleri öne çıkan özellikler.

Bir .NET projesi için tam Copilot CLI oturumu Autopilot modunda henüz denemediyseniz bu sürüm başlamak için iyi bir zaman. Sadece izinlerinizi ayarlamayı ve bırakıp gidermeyi unutmayın.

VS Code 1.112’yi indirin veya Help > Check for Updates aracılığıyla VS Code içinden güncelleyin.

Foundry Agent Service GA'ya Geçti: .NET Agent Geliştiricileri İçin Gerçekten Önemli Olan Nedir?

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Kabul edelim — bir AI agent prototipi oluşturmak kolay kısım. Zor olan ise sonrasındaki her şey: uygun ağ izolasyonuyla üretime almak, gerçekten anlamlı değerlendirmeler yapmak, uyumluluk gereksinimlerini karşılamak ve gece 2’de her şeyin çökmemesini sağlamak.

Foundry Agent Service az önce GA’ya geçti ve bu sürüm tam da bu “sonrasındaki her şey” boşluğuna odaklanıyor.

Responses API Üzerine İnşa Edildi

İşte manşet haber: yeni nesil Foundry Agent Service, OpenAI Responses API üzerine kurulu. Eğer bu wire protokolüyle zaten geliştirme yapıyorsanız, Foundry’ye geçiş minimal kod değişikliği gerektiriyor. Kazandıklarınız: kurumsal güvenlik, özel ağ desteği, Entra RBAC, tam izleme ve değerlendirme — mevcut agent mantığınızın üstüne.

Mimari kasıtlı olarak açık tasarlanmış. Tek bir model sağlayıcısına veya tek bir orkestrasyon framework’üne bağlı değilsiniz. Planlama için DeepSeek, üretim için OpenAI, orkestrasyon için LangGraph kullanabilirsiniz — runtime tutarlılık katmanını halleder.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Özel Ağ Desteği: Kurumsal Engel Kaldırıldı

Bu, kurumsal benimsemeyi engelleyen sorunu ortadan kaldıran özelliktir. Foundry artık BYO VNet ile uçtan uca tam özel ağ desteği sunuyor:

Genel çıkış yok — agent trafiği hiçbir zaman genel internete çıkmıyor
Container/alt ağ enjeksiyonu yerel iletişim için ağınıza entegre ediliyor
Araç bağlantısı dahil — MCP server’lar, Azure AI Search, Fabric data agent’ları hepsi özel yollar üzerinden çalışıyor

Son nokta kritik. Yalnızca çıkarım çağrıları değil, her araç çağrısı ve her veri alma işlemi de ağ sınırınızın içinde kalıyor. Dışarıya yönlendirmeyi yasaklayan veri sınıflandırma politikaları altında çalışan ekipler için işte bu eksik olan parçaydı.

Doğru Yapılmış MCP Kimlik Doğrulaması

MCP server bağlantıları artık tüm auth pattern yelpazesini destekliyor:

Auth Yöntemi	Ne Zaman Kullanılır
Key tabanlı	Kurum geneli dahili araçlar için basit paylaşımlı erişim
Entra Agent Identity	Servisten servise; agent kendisi olarak kimlik doğrular
Entra Managed Identity	Proje bazında izolasyon; kimlik bilgisi yönetimi yok
OAuth Identity Passthrough	Kullanıcı delegeli erişim; agent kullanıcılar adına hareket eder

OAuth Identity Passthrough ilginç olan. Kullanıcıların bir agent’a kişisel verilerine — OneDrive’larına, Salesforce organizasyonlarına, kullanıcı kapsamlı bir SaaS API’sine — erişim vermesi gerektiğinde, agent standart OAuth akışlarıyla onlar adına hareket eder. Herkesi temsil etmeye çalışan paylaşımlı bir sistem kimliği yok.

Voice Live: Tesisatla Uğraşmadan Konuşmadan Konuşmaya

Bir agent’a ses eklemek eskiden STT, LLM ve TTS’i bir araya getirmek anlamına geliyordu — üç servis, üç gecikme adımı, üç faturalama yüzeyi, hepsi elle senkronize. Voice Live bunu tek bir yönetilen API’ye indirgiyor:

Semantik ses aktivitesi ve konuşma sonu algılama (anlamı anlıyor, sadece sessizliği değil)
Sunucu taraflı gürültü bastırma ve yankı giderme
Araya girme desteği (kullanıcılar yanıt ortasında sözü kesebilir)

Ses etkileşimleri, metinle aynı agent runtime’ından geçiyor. Aynı değerlendiriciler, aynı izler, aynı maliyet görünürlüğü. Müşteri desteği, saha hizmeti veya erişilebilirlik senaryoları için bu, daha önce özel bir ses pipeline’ı gerektiren şeyin yerini alıyor.

Değerlendirmeler: Onay Kutusundan Sürekli İzlemeye

Foundry’nin üretim kalitesi konusunda ciddiye geldiği yer burası. Değerlendirme sistemi artık üç katmana sahip:

Hazır değerlendiriciler — tutarlılık, alaka, temellendirilme, erişim kalitesi, güvenlik. Bir veri kümesine veya canlı trafiğe bağlayın, puanları geri alın.
Özel değerlendiriciler — kendi iş mantığınızı, ton standartlarınızı ve alana özgü uyumluluk kurallarınızı kodlayın.
Sürekli değerlendirme — Foundry canlı üretim trafiğini örnekliyor, değerlendirici paketinizi çalıştırıyor ve sonuçları dashboard’lar aracılığıyla sunuyor. Temellendirilme düştüğünde veya güvenlik eşikleri aşıldığında Azure Monitor uyarıları ayarlayın.

Her şey Azure Monitor Application Insights’a yayımlanıyor. Agent kalitesi, altyapı sağlığı, maliyet ve uygulama telemetrisi — hepsi tek bir yerde.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Barındırılan Agent’lar İçin Altı Yeni Bölge

Barındırılan agent’lar artık East US, North Central US, Sweden Central, Southeast Asia, Japan East ve daha fazlasında kullanılabilir. Bu, veri yerleşim gereksinimleri için ve agent’ınız veri kaynaklarına yakın çalıştığında gecikmeyi azaltmak için önemlidir.

.NET Geliştiricileri İçin Neden Önemli?

GA duyurusundaki kod örnekleri Python öncelikli olsa da, altta yatan altyapı dilden bağımsız — ve azure-ai-projects için .NET SDK aynı pattern’leri takip ediyor. Responses API, değerlendirme framework’ü, özel ağ desteği, MCP auth — bunların hepsi .NET’ten erişilebilir.

AI agent’larının “harika demo” aşamasından “bunu işte gerçekten gönderebilirim” aşamasına geçmesini bekliyorsanız, bu GA sürümü sinyaldir. Özel ağ desteği, uygun auth, sürekli değerlendirme ve üretim izleme — işte eksik olan parçalar bunlardı.

Son Söz

Foundry Agent Service şu anda kullanılabilir. SDK’yı kurun, portal’ı açın ve geliştirmeye başlayın. Hızlı başlangıç kılavuzu sıfırdan çalışan bir agent’a dakikalar içinde ulaştırıyor.

Tüm kod örnekleriyle birlikte tam teknik derinlemesine bakış için GA duyurusunu inceleyin.

Microsoft Agent Framework'te Arka Plan Yanıtları: Zaman Aşımı Kaygısına Son

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

o3 veya GPT-5.2 gibi akıl yürütme modelleriyle bir şeyler geliştirdiyseniz, o acıyı biliyorsunuzdur. Agent’ınız karmaşık bir görev üzerinde düşünmeye başlıyor, istemci beklemeye devam ediyor ve “bu tamam” ile “çöktü mü acaba?” arasında bir yerde bağlantınız zaman aşımına uğruyor. Tüm o emek? Gitti.

Microsoft Agent Framework yeni arka plan yanıtlarını yayınladı — ve dürüst olmak gerekirse bu, ilk günden beri var olması gereken özelliklerden biri.

Engelleyen çağrıların sorunu

Geleneksel istek-yanıt kalıbında, agent işini bitirene kadar istemciniz bekler. Hızlı görevler için bu sorunsuz çalışır. Ama bir akıl yürütme modelinden derin araştırma, çok adımlı analiz veya 20 sayfalık rapor oluşturması istediğinizde? Gerçek zamanlı dakikalar söz konusu. Bu pencerede:

HTTP bağlantıları zaman aşımına uğrayabilir
Ağ kesintileri tüm işlemi mahvedebilir
Kullanıcınız bir şeylerin olup olmadığını merak ederek dönen bir simgeye bakmak zorunda kalır

Arka plan yanıtları bunu tersine çeviriyor.

Continuation token’lar nasıl çalışır

Engellemek yerine, agent görevini başlatırsınız ve geriye bir continuation token alırsınız. Bunu bir tamirhanedeki teslimat fişi gibi düşünün — tezgahın önünde beklemezsiniz, hazır olduğunda gelirsiniz.

Akış basit:

AllowBackgroundResponses = true ile isteğinizi gönderin
Agent arka plan işlemeyi destekliyorsa bir continuation token alırsınız
Token null döndürene kadar kendi zamanlamanızda sorgulama yapın — bu, sonucun hazır olduğu anlamına gelir

.NET versiyonu şöyle:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Tamamlanana kadar sorgula
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Agent hemen tamamlarsa (basit görevler, arka plan işleme gerektirmeyen modeller), continuation token döndürülmez. Kodunuz sadece çalışır — özel bir işlem gerekmez.

Devam ettirme özellikli streaming: asıl sihir

Sorgulama, fırlat-unut senaryoları için uygun, ama gerçek zamanlı ilerleme izlemek istediğinizde ne olur? Arka plan yanıtları aynı zamanda yerleşik devam ettirme özelliğiyle streaming’i de destekliyor.

Her streaming güncellemesi kendi continuation token’ını taşıyor. Bağlantınız streaming ortasında kesilirse, tam kaldığınız yerden devam ediyorsunuz:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Ağ kesintisini simüle et
}

// Tam kaldığımız yerden devam et
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent, istemcinizde ne olursa olsun sunucu tarafında işlemeye devam ediyor. Bu, retry mantığı veya circuit breaker yazmadan yerleşik hata toleransı demek.

Bunu gerçekten ne zaman kullanmalısınız

Her agent çağrısının arka plan yanıtlarına ihtiyacı yok. Hızlı tamamlamalar için gereksiz yere karmaşıklık ekliyor olursunuz. Ama bunların parlattığı durumlar şunlar:

Karmaşık akıl yürütme görevleri — çok adımlı analiz, derin araştırma, bir akıl yürütme modelinin gerçekten düşünmesi gereken her şey
Uzun içerik üretimi — ayrıntılı raporlar, çok bölümlü belgeler, kapsamlı analizler
Güvenilmez ağlar — mobil istemciler, edge dağıtımlar, kararsız kurumsal VPN’ler
Asenkron UX kalıpları — görevi gönder, başka bir şey yap, sonuçlar için geri gel

Kurumsal uygulamalar geliştiren .NET geliştiricileri olarak bizim için özellikle son madde ilginç. Kullanıcının karmaşık bir rapor talep ettiği bir Blazor uygulaması düşünün — agent görevini başlatırsınız, ilerleme göstergesi gösterirsiniz ve kullanıcının çalışmaya devam etmesine izin verirsiniz. WebSocket karmaşası yok, özel kuyruk altyapısı yok, sadece bir token ve bir sorgulama döngüsü.

Sonuç

Arka plan yanıtları Microsoft Agent Framework üzerinden şu anda hem .NET hem de Python’da mevcut. Basit soru-cevabın ötesinde herhangi bir şey yapan agent’lar geliştiriyorsanız, bunu araç kutunuza eklemeye değer. Continuation token kalıbi, gerçek bir üretim sorununu çözerken işleri basit tutuyor.

Tam API referansı ve daha fazla örnek için belgelere bakın.

Dotnet | The .NET Blog

Python, TypeScript ve .NET ile azd Hook Yazma: Shell Script'lere Veda

Hook nedir?

Algılama nasıl çalışır

Dile göre önemli ayrıntılar

Python

JavaScript ve TypeScript

.NET

Executor’a özgü yapılandırma

.NET geliştiricileri için önemi

Sonuç

Windows App Dev CLI v0.3: Terminalden F5 Hata Ayıklama ve Ajanlar için UI Otomasyonu

winapp run: Her yerden F5

Yeni NuGet Paketi: Paketlenmiş uygulamalar için dotnet run

winapp ui: Komut satırından UI Otomasyonu

Diğer yenilikler

Nasıl edinilir

Terminalinizi Serbest Bırakın: Aspire'ın Detached Modu İş Akışını Değiştiriyor

Detached mod: bir komut, terminal geri

Çalışanları yönetmek

Isolated modla birleştirin

Bu neden kodlama ajanları için büyük bir gelişme

Özet

.NET MAUI Maps'e Nihayet Pin Kümeleme Geldi — Tek Özellik, Sıfır Acı

Hepsini Yöneten Tek Özellik

Bağımsız Kümeleme Grupları

Küme Tap’larını Yönetme

Bilmeye Değer Platform Ayrıntıları

Neden Önemli?

Başlarken

.NET Nisan 2026 Bakım Güncellemesi — Bugün Uygulamanız Gereken Güvenlik Yamaları

Neler yamalandı

Güncellenen sürümler

Ne yapmalısınız

Azure MCP Server 2.0 Yayınlandı — Self-Hosted Agentic Bulut Otomasyonu Artık Burada

Azure MCP Server nedir?

Büyük haber: self-hosted uzak dağıtımlar

Güvenlik güçlendirmesi

Nerede kullanabilirsiniz?

Bu .NET geliştiricileri için neden önemli

Başlarken

Sonuç

.NET Aspire 13.2 AI Ajanınızın En İyi Dostu Olmak İstiyor

Sorun gerçek

Ajan altyapısı olarak Aspire

Bowling koruma bandı analojisi

Başlarken

Özet

Aspire'ın Isolated Modu Paralel Geliştirmedeki Port Çakışma Kabusu'nu Çözüyor

Çözüm: --isolated

Bunun parladığı gerçek senaryolar

Arka planda nasıl çalışıyor

Ne zaman kullanmalı

Özet

Azure Functions Üzerindeki MCP Server'larınızı Foundry Agent'larına Bağlayın — İşte Nasıl Yapılır

Bu Kombinasyon Neden Mantıklı?

Kimlik Doğrulama Seçenekleri

Kurulum

Değerlendirmem

Son Söz

GitHub Copilot'un Modernizasyon Değerlendirmesi, Henüz Kullanmadığınız En İyi Göç Aracı

Bu sadece bir kod öneri motoru değil

Başlamanın iki yolu

Sorun dökümü uygulanabilir

Kapsanan yükseltme yolları

Benim düşüncem

Sonuç

MCP Uygulamaları Fluent API Kazandı — .NET'te Üç Adımda Zengin AI Araç Arayüzleri Oluşturun

MCP Apps Nedir?

Üç Adımda Fluent API

API Yüzeyi İyi Tasarlanmış

Başlarken

Son Söz

C# 15 Union Türlerini Alıyor — ve Bunlar Tam İstediğimiz Şey

Union türlerinin çözdüğü sorun

Sözdizimi güzelce basit

Bu pratikte ne anlama geliyor

Farklı şekiller döndüren API yanıtları

Tek değer veya koleksiyon

İlgisiz türleri birleştirme

Çözüm: `--isolated`