Developer-Tools | The .NET Blog

Azure MCP Server Artık .mcpb — Herhangi Bir Runtime Olmadan Yükle

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

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

MCP sunucularını kurarken can sıkıcı olan ne olduğunu biliyor musunuz? Bir runtime gerekiyordu. npm sürümü için Node.js, pip/uvx için Python, dotnet varyantı için .NET SDK.

Azure MCP Server bunu değiştirdi. Artık .mcpb — MCP Bundle — olarak kullanılabilir ve kurulum sürükle-bıraktır.

MCP Bundle Nedir?

VS Code uzantısı (.vsix) veya tarayıcı uzantısı (.crx) gibi düşünün, ama MCP sunucuları için. .mcpb dosyası, sunucu ikilisini ve tüm bağımlılıklarını içeren bağımsız bir ZIP arşividir.

Nasıl Kurulur

1. Platformunuz için bundle’ı indirin

GitHub Releases sayfasına gidin ve OS ve mimarinize uygun .mcpb dosyasını indirin.

2. Claude Desktop’a kurun

En kolay yol: Uzantılar ayarları sayfasındayken (☰ → Dosya → Ayarlar → Uzantılar) .mcpb dosyasını Claude Desktop penceresine sürükleyip bırakın. Sunucu ayrıntılarını inceleyin, Yükle’ye tıklayın, onaylayın.

3. Azure’da kimlik doğrulaması yapın

az login

Başlamak için

İndirme: GitHub Releases
Depo: aka.ms/azmcp
Belgeler: aka.ms/azmcp/docs

Tam makaleye bakın.

VS Code 1.118: Copilot CLI Oturum Adları, Model Rozetleri ve TypeScript 7.0 Nightly Alıyor

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

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

Visual Studio Code 1.118, ağırlıklı olarak Copilot CLI iyileştirmelerine odaklanan küçük bir sürümdür.

Copilot CLI: Oturumlara Gerçek Adlar Geliyor

Copilot CLI SDK oturum başlığı API’leri artık oturum adları için doğruluk kaynağı olarak kullanılıyor. Otomatik oluşturulan etiketler yerine SDK’daki gerçek ad gösteriliyor.

Klavye Kısayollarıyla Hızlı Oturum Değiştirme

Agents uygulamasına artık oturumlar arasında hızla geçiş için Ctrl+1, Ctrl+2 vb. tuş atamaları eklendi.

Sohbette Model Rozetleri

Copilot CLI’nin sohbet panelindeki yanıtlarında artık model rozeti gösteriliyor.

Copilot CLI’da Otomatik Model Seçimi

Otomatik model seçimi özelliği artık Copilot CLI ajanında da çalışıyor.

TypeScript 7.0 Nightly Katılımı

Artık VS Code ayarlarından doğrudan TypeScript 7.0 nightly sürümlerini test etmeyi etkinleştirebilirsiniz. TypeScript 7.0 önemli bir sürümdür (beta birkaç gün önce yayınlandı).

Tam sürüm notlarına bakın.

Foundry Toolboxes: Tüm Ajan Araçları için Tek Bir Endpoint

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.

Bizzat yaşayana kadar önemsiz görünen bir sorun var: Kuruluş birden fazla yapay zeka ajanı oluşturuyor, her birinin araçlara ihtiyacı var ve her ekip sıfırdan yapılandırıyor. Aynı web arama entegrasyonu, aynı Azure AI Search yapılandırması, aynı GitHub MCP sunucusu bağlantısı — ama farklı bir depoda, farklı bir ekip tarafından, farklı kimlik bilgileriyle ve paylaşılan yönetim olmadan.

Microsoft Foundry, genel önizlemede Toolboxes yayımladı ve bu soruna doğrudan bir yanıt niteliğinde.

Toolbox nedir?

Toolbox, Foundry’de bir kez tanımlanıp tek bir MCP uyumlu endpoint üzerinden sunulan, adlandırılmış ve yeniden kullanılabilir bir araç paketidir. MCP konuşabilen herhangi bir ajan çalışma zamanı bunu tüketebilir — Foundry Agents’a bağımlılık yoktur.

Vaat basittir: build once, consume anywhere. Araçları tanımla, kimlik doğrulamayı merkezi olarak yapılandır (OAuth doğrudan geçiş, Entra yönetilen kimlik), endpoint’i yayımla. Bu araçlara ihtiyaç duyan her ajan endpoint’e bağlanır ve tümünü alır.

Dört sütun (bugün ikisi mevcut)

Sütun	Durum	Ne yapar
Discover	Yakında	Elle arama yapmadan onaylı araçları bulma
Build	Mevcut	Araçları yeniden kullanılabilir pakete gruplama
Consume	Mevcut	Tek MCP endpoint tüm araçları sunar
Govern	Yakında	Merkezi kimlik doğrulama + tüm araç çağrılarının gözlemlenebilirliği

Pratik örnek

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Dokümanlarda arama yap ve GitHub sorunlarına yanıt ver.",
 tools=[
 {"type": "web_search", "description": "Genel belgelerde arama yap"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Yayımlandıktan sonra Foundry birleşik bir endpoint sağlar. Tek bağlantı, tüm araçlar.

Foundry Agents’a bağımlılık yok

Toolboxes, Foundry’de oluşturulur ve yönetilir; ancak tüketim yüzeyi açık MCP protokolüdür. Bunları özel ajanlardan (Microsoft Agent Framework, LangGraph), GitHub Copilot ve diğer MCP destekli IDE’lerden kullanabilirsiniz.

Neden şimdi önemli?

Çoklu ajan dalgası üretime ulaşıyor. Her yeni ajan, yinelenen yapılandırma, eski kimlik bilgileri ve tutarsız davranış için yeni bir yüzeydir. Build + Consume temeli merkezileşmeye başlamak için yeterlidir. Govern sütunu geldiğinde, tüm ajan filosu için tam gözlemlenebilir ve merkezi olarak kontrol edilen bir araç katmanı elde edilmiş olacak.

Sonuç

Henüz erken — genel önizleme, önce Python SDK, Discover ve Govern henüz yolda. Ancak model sağlam ve MCP yerel tasarımı, zaten inşa ettiğiniz araçlarla çalıştığı anlamına geliyor. Ayrıntılar için resmi duyuruya bakın.

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.

VS Code 1.117: Agentlar Artık Kendi Git Dallarını Alıyor ve Ben Bunun İçin Buradayım

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

“AI asistanı” ile “AI takım üyesi” arasındaki çizgi giderek inceliyor. VS Code 1.117 az önce yayınlandı ve tam sürüm notları çok şey içeriyor, ancak buradaki hikaye açık: agentlar geliştirme iş akışınızda birinci sınıf vatandaş haline geliyor.

İşte gerçekten önemli olan şeyler.

Autopilot modu artık tercihinizi hatırlıyor

Daha önce her yeni oturum başlattığınızda Autopilot’u yeniden etkinleştirmeniz gerekiyordu. Can sıkıcıydı. Artık izin modunuz oturumlar arasında korunuyor ve varsayılanı yapılandırabiliyorsunuz.

Agent Host üç oturum yapılandırmasını destekliyor:

Default — araçlar çalışmadan önce onay istiyor
Bypass — her şeyi otomatik onaylıyor
Autopilot — tamamen özerk, kendi sorularını yanıtlıyor ve devam ediyor

Migrasyonlar, Docker ve CI ile yeni bir .NET projesi kuruyorsanız — Autopilot’u bir kez ayarlayın ve unutun. O tercih kalıcı.

Agent oturumları için worktree ve git izolasyonu

Bu en büyük özellik. Agent oturumları artık tam worktree ve git izolasyonunu destekliyor. Bu, bir agent bir görev üzerinde çalışırken kendi dalını ve çalışma dizinini aldığı anlamına geliyor. Ana dalınız dokunulmadan kalıyor.

Daha da iyisi — Copilot CLI bu worktree oturumları için anlamlı dal adları üretiyor. Artık agent-session-abc123 yok. Agentin ne yaptığını gerçekten açıklayan bir şey alıyorsunuz.

Birden fazla özellik dalı üzerinde çalışan veya uzun bir iskele görevi çalışırken hata düzelten .NET geliştiricileri için bu oyun değiştirici. Bir worktree’de API controller’larınızı oluşturan bir agent varken siz başka bir worktree’de servis katmanı sorununu ayıklıyor olabilirsiniz. Çakışma yok. Stash yok. Karmaşa yok.

Alt-agentlar ve agent ekipleri

Agent Host Protocol artık alt-agentları destekliyor. Bir agent, bir görevin parçalarını yönetmek için başka agentlar çalıştırabilir. Görevlendirme gibi düşünün — ana agent koordine eder, uzman agentlar parçaları yönetir.

Bu erken aşamada, ancak .NET iş akışları için potansiyel açık. EF Core migrasyonlarınızı yöneten bir agent varken diğeri entegrasyon testlerinizi kuruyor, bunu hayal edin. Tam olarak oraya henüz ulaşmadık, ancak protokol desteğinin şimdi gelmesi tooling’in hızla takip edeceği anlamına geliyor.

Agentlar girdi gönderdiğinde terminal çıktısı otomatik dahil ediliyor

Küçük ama anlamlı. Bir agent terminale girdi gönderdiğinde, terminal çıktısı artık otomatik olarak bağlama dahil ediliyor. Daha önce, agent ne olduğunu görmek için ekstra bir tur atmak zorundaydı.

Bir agentin dotnet build çalıştırdığını, başarısız olduğunu ve ardından hatayı görmek için başka bir gidiş-dönüş yaptığını izlediyseniz — bu sürtünme gitti. Çıktıyı hemen görüyor ve tepki veriyor.

macOS’ta Agents uygulaması kendi kendini güncelliyor

macOS’taki bağımsız Agents uygulaması artık kendi kendini güncelliyor. Artık yeni sürümleri manuel olarak indirmeye gerek yok. Güncel kalıyor.

Bilmeye değer küçük şeyler

package.json hover’ları artık hem yüklü sürümü hem de mevcut en son sürümü gösteriyor. .NET projelerinizin yanında npm tooling yönetiyorsanız kullanışlı.
JSDoc yorumlarındaki resimler hover ve tamamlamalarda doğru şekilde render ediliyor.
Copilot CLI oturumları artık VS Code tarafından mı yoksa harici olarak mı oluşturulduklarını gösteriyor — terminaller arasında atlıyorsanız kullanışlı.
Copilot CLI, Claude Code ve Gemini CLI kabuk türleri olarak tanınıyor. Editör ne çalıştırdığınızı biliyor.

Sonuç

VS Code 1.117 gösterişli bir özellik yığını değil. Altyapı. Worktree izolasyonu, kalıcı izinler, alt-agent protokolleri — bunlar, agentların kodunuza basmadan gerçek, paralel görevleri üstlendiği bir iş akışının yapı taşları.

.NET ile geliştirme yapıyorsanız ve henüz ajanlı iş akışına girmediyseniz, dürüstçe söylemek gerekirse, başlamak için şimdi tam zamanı.

Docker Sandbox, Copilot Agent'larının Makinenizi Tehlikeye Atmadan Kodunuzu Yeniden Düzenlemesini Sağlıyor

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

Copilot’un agent modunu küçük düzenlemelerin ötesinde bir şey için kullandıysanız, acısını bilirsiniz. Her dosya yazma işlemi, her terminal komutu — bir izin isteği daha. Bunu 50 proje boyunca çalıştırdığınızı düşünün. Hiç eğlenceli değil.

Azure ekibi, GitHub Copilot agent’ları için Docker Sandbox hakkında bir yazı yayımladı ve dürüst olmak gerekirse, bu gördüğüm en pratik agentic araç geliştirmelerinden biri. MicroVM’ler kullanarak Copilot’a tamamen izole bir ortam sağlıyor; orada istediği gibi davranabilir — paket yükleyebilir, build çalıştırabilir, testleri yürütebilir — ana sisteminize dokunmadan.

Docker Sandbox size gerçekte ne veriyor

Temel fikir basit: tam Linux ortamıyla hafif bir microVM başlatın, çalışma alanınızı içine senkronize edin ve Copilot agent’ının içinde serbestçe çalışmasına izin verin. İşi bittiğinde değişiklikler geri senkronize edilir.

Bunu sadece “bir container’da bir şeyler çalıştır"dan fazlası yapan şeyler şunlar:

Mutlak yolları koruyan çift yönlü çalışma alanı senkronizasyonu. Proje yapınız sandbox içinde tamamen aynı görünür. Yol kaynaklı build hataları yok.
MicroVM içinde çalışan özel Docker daemon. Agent, ana makinenizin Docker soketini bağlamak zorunda kalmadan container oluşturabilir ve çalıştırabilir. Güvenlik açısından bu büyük bir kazanım.
Agent’ın ağda neye erişebileceğini kontrol eden HTTP/HTTPS filtreleme proxy’leri. Hangi registry’lere ve endpoint’lere izin verildiğine siz karar verirsiniz. Sandbox içindeki bir npm install‘dan gelen tedarik zinciri saldırıları mı? Engellendi.
YOLO modu — evet, gerçekten böyle çağırıyorlar. Agent izin istemi olmadan çalışıyor çünkü ana makinenize gerçekten zarar veremez. Her yıkıcı eylem sandbox içinde kalıyor.

.NET geliştiricilerinin neden önemsemesi gerekiyor

Pek çok ekibin şu an karşı karşıya olduğu modernizasyon işini düşünün. .NET 9’a taşımanız gereken, 30 projelik bir .NET Framework çözümünüz var. Bu yüzlerce dosya değişikliği demek — proje dosyaları, namespace güncellemeleri, API değişiklikleri, NuGet geçişleri.

Docker Sandbox ile bir Copilot agent’ını bir projeye yönlendirebilir, microVM içinde serbestçe yeniden düzenlemesine izin verebilir, doğrulama için dotnet build ve dotnet test çalıştırabilir ve yalnızca gerçekten çalışan değişiklikleri kabul edebilirsiniz. Denemeler yaparken yerel geliştirme ortamınızı yanlışlıkla mahvetme riski yok.

Yazı ayrıca paralel agent filosu çalıştırmayı da anlatıyor — her biri kendi sandbox’ında — farklı projeleri aynı anda ele alıyor. Büyük .NET çözümleri veya microservice mimarileri için bu muazzam bir zaman tasarrufu. Servis başına bir agent, hepsi izole çalışıyor, hepsi bağımsız olarak doğrulanıyor.

Güvenlik boyutu önemli

İnsanların çoğunlukla atladığı şey şu: bir AI agent’ının rastgele komutlar yürütmesine izin verdiğinizde, ona tüm makinenizle güveniyorsunuz demektir. Docker Sandbox bu modeli tersine çeviriyor. Agent, tek kullanımlık bir ortam içinde tam özerklik alıyor. Ağ proxy’si yalnızca onaylanan kaynaklardan çekebilmesini sağlıyor. Ana makine dosya sisteminiz, Docker daemon’unuz ve kimlik bilgileriniz dokunulmadan kalıyor.

Uyumluluk gereksinimleri olan ekipler için — ki bu çoğu kurumsal .NET mağazasıdır — bu, “agentic AI kullanamayız” ile “güvenle benimseyelim” arasındaki farktır.

Sonuç

Docker Sandbox, agentic kodlamanın temel gerilimini çözüyor: agent’ların kullanışlı olabilmek için özgürlüğe ihtiyacı var, ama ana makinenizde özgürlük tehlikelidir. MicroVM’ler her ikisini de sunuyor. Büyük ölçekli herhangi bir .NET yeniden düzenleme veya modernizasyon planı yapıyorsanız, bunu şimdi kurmaya değer. Copilot’un kod zekasını güvenli bir yürütme ortamıyla birleştirmek, üretim ekiplerinin beklediği tam olarak bu.

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.

Azure MCP Araçları Artık Visual Studio 2022'ye Entegre — Uzantı Gerekmiyor

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

Azure MCP araçlarını ayrı uzantı üzerinden Visual Studio’da kullandıysanız, süreci biliyorsunuzdur — VSIX’i kurun, yeniden başlatın, bir şeylerin bozulmamasını umun, sürüm uyumsuzluklarıyla uğraşın. O sürtünme artık tarihe karışıyor.

Yun Jung Choi duyurdu: Azure MCP araçları artık Visual Studio 2022’de Azure geliştirme iş yükünün doğrudan bir parçası olarak geliyor. Uzantı yok. VSIX yok. Yeniden başlatma dansı yok.

Bu aslında ne anlama geliyor

Visual Studio 2022 sürüm 17.14.30 itibarıyla Azure MCP Server, Azure geliştirme iş yüküyle birlikte geliyor. Bu iş yükünü zaten yüklediyseniz, tek yapmanız gereken GitHub Copilot Chat’te etkinleştirip kullanmaya başlamak.

45 Azure servisi genelinde 230’dan fazla araç — doğrudan sohbet penceresinden erişilebilir. Depolama hesaplarınızı listeleyin, ASP.NET Core uygulaması dağıtın, App Service sorunlarını tanılayın, Log Analytics’i sorgulayın — tek bir tarayıcı sekmesi açmadan.

Bu neden göründüğünden daha önemli

Geliştirici araçlarındaki şu gerçeği biliyoruz: her ekstra adım sürtünmedir, sürtünme ise benimsemeyi öldürür. MCP’nin ayrı bir uzantı olması; sürüm uyumsuzlukları, kurulum hataları ve güncel tutulması gereken bir şey daha demekti. İş yüküne entegre etmek şu anlama geliyor:

Visual Studio Installer üzerinden tek güncelleme yolu
Uzantı ile IDE arasında sürüm kayması yok
Her zaman güncel — MCP Server, düzenli VS sürümleriyle birlikte güncelleniyor

Azure üzerinde standartlaştıran ekipler için bu büyük bir avantaj. İş yükünü bir kez kuruyorsunuz, araçları etkinleştiriyorsunuz ve her oturumda hazır oluyorlar.

Bununla neler yapabilirsiniz

Araçlar Copilot Chat üzerinden tüm geliştirme yaşam döngüsünü kapsıyor:

Öğrenin — Azure servisleri, en iyi pratikler, mimari kalıplar hakkında sorular sorun
Tasarlayın ve geliştirin — servis önerileri alın, uygulama kodunu yapılandırın
Dağıtın — kaynakları sağlayın ve doğrudan IDE’den dağıtın
Sorun giderin — günlükleri sorgulayın, kaynak sağlığını kontrol edin, üretim sorunlarını tanılayın

Hızlı bir örnek — Copilot Chat’e şunu yazın:

List my storage accounts in my current subscription.

Copilot, arka planda Azure MCP araçlarını çağırır, aboneliklerinizi sorgular ve isimler, konumlar ve SKU’larla birlikte biçimlendirilmiş bir liste döndürür. Portal gerekmez.

Nasıl etkinleştirilir

Visual Studio 2022 17.14.30 veya üzerine güncelleyin
Azure development iş yükünün yüklendiğinden emin olun
GitHub Copilot Chat’i açın
Select tools düğmesine tıklayın (iki İngiliz anahtarı simgesi)
Azure MCP Server‘ı etkinleştirin

Hepsi bu. Oturumlar arasında etkin kalır.

Bir not

Araçlar varsayılan olarak devre dışıdır — katılımınız gerekiyor. VS 2026’ya özgü araçlar VS 2022’de mevcut değil. Araç kullanılabilirliği de portaldaki gibi Azure abonelik izinlerinize bağlı.

Büyük resim

Bu, net bir trendin parçası: MCP, bulut araçlarını geliştirici IDE’lerinde sunmanın standart yolu haline geliyor. Azure MCP Server 2.0 kararlı sürümünü ve VS Code ile diğer editörlerdeki MCP entegrasyonlarını zaten gördük. Visual Studio’nun iş yükü sistemine entegre olması doğal bir ilerleme.

Visual Studio’da yaşayan .NET geliştiricileri olarak bu, Azure portalına bağlam değiştirmek için bir neden daha ortadan kalkıyor. Ve dürüst olmak gerekirse, ne kadar az sekme değiştirirsek o kadar iyi.

azd update — Tüm Paket Yöneticileriniz İçin Tek Bir Komut

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

Her birkaç haftada bir beliren “azd’nin yeni bir sürümü mevcut” mesajını biliyor musunuz? azd‘yi winget, Homebrew veya altı ay önce çalıştırdığınız curl betiğiyle mi yüklediğinizi hatırlayamadığınız için görmezden geldiğiniz mesajı? Evet, bu sonunda düzeldi.

Microsoft, azd update‘i piyasaya sürdü — Azure Developer CLI’ı, başlangıçta nasıl yüklediğinizden bağımsız olarak en son sürüme güncelleyen tek bir komut. Windows, macOS, Linux — fark etmiyor. Tek komut.

Nasıl çalışıyor

azd update

Hepsi bu. Yeni özelliklere erken erişim istiyorsanız, günlük insiders derlemesine geçebilirsiniz:

azd update --channel daily
azd update --channel stable

Komut, mevcut kurulum yönteminizi algılar ve arka planda uygun güncelleme mekanizmasını kullanır. Artık “bu makinede winget mi yoksa choco mu kullandım?” sorusuna gerek yok.

Küçük bir uyarı

azd update, 1.23.x sürümünden itibaren gönderilmeye başlandı. Daha eski bir sürümdeyseniz, orijinal kurulum yönteminizi kullanarak son bir manuel güncelleme yapmanız gerekecek. Bundan sonra azd update her şeyi halleder.

Mevcut sürümünüzü azd version ile kontrol edin. Yeni bir kuruluma ihtiyacınız varsa, kurulum dokümanları size yol gösterir.

Neden önemli

Bu küçük bir yaşam kalitesi iyileştirmesi, ancak Azure’a AI ajanları ve Aspire uygulamaları dağıtmak için azd‘yi günlük kullananlar için güncel kalmak daha az “bu hata zaten son sürümde düzeltilmişti” anı demek. Düşünmek zorunda kalmamanız gereken bir şey daha.

Daha fazla bağlam için tam duyuruyu ve Jon Gallant’ın daha ayrıntılı incelemesini okuyun.

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

O Visual Studio Kayan Pencere Ayarını Hiç Duydunuz mu? (Duymanız Gerekiyor)

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

Birden fazla monitörle Visual Studio kullanıyorsanız (ve dürüstçe söylemek gerekirse, günümüzde kim kullanmıyor ki), muhtemelen o can sıkıcı durumu yaşamışsınızdır: ana IDE’yi küçülttüğünüzde kayan araç pencereleri kayboluyor, her zaman her şeyin üstünde kalıyor ve ayrı görev çubuğu butonları olarak görünmüyorlar. Bazı iş akışları için işe yarayabilir, ancak çoklu monitör kurulumlarında oldukça sinir bozucu.

Visual Studio ekibinden Mads Kristensen, kayan pencerelerin davranışını kökten değiştiren az bilinen bir ayarı paylaştı. Tek bir açılır menü. Hepsi bu kadar.

Ayar nerede?

Tools > Options > Environment > Windows > Floating Windows

“These floating windows are owned by the main window” açılır menüsünde üç seçenek bulunuyor:

None — tam bağımsızlık. Her kayan pencere kendi görev çubuğu girişini alır ve normal bir Windows penceresi gibi davranır.
Tool Windows (varsayılan) — belgeler serbestçe kalar, araç pencereleri IDE’ye bağlı kalır.
Documents and Tool Windows — klasik Visual Studio davranışı, her şey ana pencereye bağlı.

Çoklu monitör kurulumlarında neden “None” doğru seçim?

None olarak ayarlayın ve aniden tüm kayan araç pencereleriniz ve belgeleriniz gerçek Windows uygulamaları gibi davranmaya başlar. Görev çubuğunda görünürler, ana Visual Studio penceresini küçülttüğünüzde görünür kalmaya devam ederler ve artık her şeyin önüne zorla gelmiyor.

Bunu PowerToys FancyZones ile birleştirirseniz oyun değiştirucu bir deneyim elde edersiniz. Monitörlerinizde özel düzenler oluşturun, Solution Explorer’ınızı bir bölgeye, hata ayıklayıcıyı bir diğerine ve kod dosyalarını istediğiniz yere yerleştirin. Her şey yerinde kalır, her şeye bağımsız olarak erişilebilir ve çalışma alanınız kaotik yerine düzenli hissedilir.

Hızlı öneriler

Çoklu monitör güç kullanıcıları: None olarak ayarlayın, FancyZones ile birleştirin
Ara sıra kayan pencere kullananlar: Tool Windows (varsayılan) sağlam bir orta yol
Geleneksel iş akışı: Documents and Tool Windows her şeyi klasik tutar

İpucu: Herhangi bir araç penceresi başlık çubuğuna Ctrl + çift tıklayarak anında kayan veya yerleşik hale getirebilirsiniz. Ayarı değiştirdikten sonra yeniden başlatmaya gerek yok.

Sonuç

Bu, “bunu neden daha önce bilmiyordum” dedirten ayarlardan biri. Visual Studio’daki kayan pencereler sizi hiç rahatsız ettiyse şu anda gidip bunu değiştirin.

Ayrıntılar ve ekran görüntüleri için tam yazıyı okuyun.

VS Code 1.116 — Agents Uygulaması Klavye Navigasyonu ve Dosya Bağlamı Tamamlamaları Kazandı

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

VS Code 1.116, Nisan 2026 sürümü; bazı yakın güncellemelerden daha hafif olsa da, değişiklikler odaklı ve anlamlı — özellikle Agents uygulamasını her gün kullanıyorsanız.

İşte resmi sürüm notlarına dayanarak neler geldi.

Agents uygulaması iyileştirmeleri

Agents uygulaması, günlük iş akışlarında gerçek fark yaratan kullanılabilirlik geliştirmeleriyle olgunlaşmaya devam ediyor:

Özel kısayol tuşları — artık Changes görünümüne, Changes içindeki dosya ağacına ve Chat Customizations görünümüne özel komutlar ve klavye kısayollarıyla odaklanabilirsiniz. Agents uygulamasında gezinmek için tıklıyorsanız, bu tam klavye odaklı iş akışlarını getiriyor.

Erişilebilirlik yardım diyaloğu — sohbet giriş kutusunda Alt+F1 tuşuna basmak artık mevcut komutları ve kısayol tuşlarını gösteren bir erişilebilirlik yardım diyaloğu açıyor. Ekran okuyucu kullanıcıları ayrıca duyuru ayrıntısını kontrol edebiliyor. İyi erişilebilirlik herkesin işine yarar.

Dosya bağlamı tamamlamaları — Agents uygulaması sohbetinde # yazarak mevcut çalışma alanınıza kapsamlı dosya bağlamı tamamlamalarını tetikleyin. Bu, her etkileşimi hızlandıran küçük bir yaşam kalitesi iyileştirmelerinden biri — koda referans verirken artık tam dosya yolları yazmak yok.

CSS `@import` bağlantı çözümlemesi

Frontend geliştiricileri için güzel bir özellik: VS Code artık node_modules yollarını kullanan CSS @import referanslarını çözümlüyor. Bundler kullanırken @import "some-module/style.css" gibi importlar üzerinden Ctrl+click yapabilirsiniz. Küçük ama CSS iş akışlarındaki bir sürtünme noktasını ortadan kaldırıyor.

Sonuç

VS Code 1.116, iyileştirmeyle ilgili — Agents uygulamasını daha kolay gezilebilir, daha erişilebilir ve klavye dostu hale getiriyor. Agents uygulamasında önemli zaman harcıyorsanız (ki pek çoğumuzun harcadığını düşünüyorum), bu değişiklikler birikir.

Tam liste için sürüm notlarına bakın.

VS Code 1.115 — Arka Plan Terminal Bildirimleri, SSH Agent Modu ve Daha Fazlası

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 az önce yayınlandı ve başlık özellikleri açısından hafif bir sürüm olsa da, AI kodlama asistanlarıyla her gün çalışıyorsanız agent ile ilgili iyileştirmeler gerçekten kullanışlı.

Gerçekten bilinmeye değer olanları öne çıkarayım.

Arka plan terminalleri agentlara geri bildirim veriyor

Bu, öne çıkan özellik. Arka plan terminalleri artık komutlar tamamlandığında çıkış kodu ve terminal çıktısını da içerecek şekilde otomatik olarak agentları bilgilendiriyor. Arka plan terminallerindeki giriş istemleri de tespit edilerek kullanıcıya iletiliyor.

Bu neden önemli? Copilot’un agent modunu arka planda build komutları veya test dizileri çalıştırmak için kullandıysanız, “o bitti mi acaba?” sancısını bilirsiniz — arka plan terminalleri esasen ateş et ve unut mantığıyla çalışıyordu. Artık agent, dotnet build veya dotnet test tamamlandığında haberdar ediliyor, çıktıyı görüyor ve buna göre tepki verebiliyor. Küçük bir değişiklik, ama agent odaklı iş akışlarını önemli ölçüde daha güvenilir kılıyor.

Ayrıca, agentların kullanıcı onayıyla arka plan terminallerine komut göndermesine olanak tanıyan yeni bir send_to_terminal aracı var; bu da run_in_terminal‘in zaman aşımıyla terminalleri arka plana taşıdığı ve salt okunur hale getirdiği sorunu çözüyor.

SSH uzak agent barındırma

VS Code artık SSH üzerinden uzak makinelere bağlanmayı, CLI’yi otomatik olarak yüklemeyi ve agent ana bilgisayar modunda başlatmayı destekliyor. Bu, AI agent oturumlarınızın uzak ortamları doğrudan hedefleyebileceği anlamına geliyor — Linux sunucularda veya bulut VM’lerinde geliştirme ve test yapan .NET geliştiricileri için kullanışlı.

Agent oturumlarında düzenleme takibi

Agent oturumları sırasında yapılan dosya düzenlemeleri artık farklar, geri alma/yeniden yapma ve durum geri yükleme ile birlikte takip ediliyor ve geri yükleniyor. Bir agent kodunuzda değişiklik yapar ve bir şeyler ters giderse, tam olarak neyin değiştiğini görebilir ve geri alabilirsiniz. Agentların kod tabanınızı değiştirmesine izin vermek için gönül rahatlığı.

Tarayıcı sekme farkındalığı ve diğer iyileştirmeler

Birkaç yaşam kalitesi iyileştirmesi daha:

Tarayıcı sekme takibi — sohbet artık bir oturum sırasında açılan tarayıcı sekmelerini takip edip bunlara bağlantı verebiliyor, böylece agentlar baktığınız web sayfalarına referans verebiliyor
Terminale dosya yapıştırma — Ctrl+V, sürükle-bırak veya sağ tıklamayla terminale dosya (resimler dahil) yapıştırın
Minimap’te test kapsamı — test kapsamı göstergeleri artık hızlı bir görsel özet için minimap’te gösteriliyor
Mac’te sıkıştırarak yakınlaştırma — entegre tarayıcı sıkıştırarak yakınlaştırma hareketlerini destekliyor
Sessions’da Copilot yetkilendirmeleri — durum çubuğu Sessions görünümünde kullanım bilgilerini gösteriyor
Go to File’da favicon — açık web sayfaları hızlı seçim listesinde favicon gösteriyor

Sonuç

VS Code 1.115 artımlı bir sürüm, ancak agent iyileştirmeleri — arka plan terminal bildirimleri, SSH agent barındırma ve düzenleme takibi — AI destekli geliştirme için fark edilir şekilde daha akıcı bir deneyim oluşturuyor. .NET projeleri için Copilot’un agent modunu kullanıyorsanız, bunlar günlük sürtünmeyi azaltan yaşam kalitesi düzeltmeleri.

Her ayrıntı için tam sürüm notlarına 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.

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.

Azure DevOps Sonunda Herkesin Şikayet Ettiği Markdown Editörü UX'ini Düzeltiyor

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

Azure Boards kullanıyorsanız, muhtemelen bunu yaşamışsınızdır: bir iş öğesi açıklamasını okuyorsunuz, belki kabul kriterlerini gözden geçiriyorsunuz ve yanlışlıkla çift tıklıyorsunuz. Bum — düzenleme modundasınız. Hiçbir şeyi düzenlemek istemiyordunuz. Sadece okuyordunuz.

Dan Hellem düzeltmeyi duyurdu, ve bu, küçük gibi görünse de günlük iş akışınızdan gerçek sürtüşmeyi kaldıran değişikliklerden biri.

Ne değişti

İş öğesi metin alanları için Markdown editörü artık varsayılan olarak önizleme modunda açılıyor. İçerikle okuyabilir ve etkileşime girebilirsiniz — bağlantıları takip etmek, biçimlendirmeyi gözden geçirmek — yanlışlıkla düzenleme moduna girme endişesi olmadan.

Gerçekten düzenlemek istediğinizde, alanın üstündeki düzenleme simgesine tıklarsınız. Bitirdiğinizde, açıkça önizleme moduna geri çıkarsınız.

Neden göründüğünden daha önemli

Bu konudaki topluluk geri bildirim dizisi uzundu. Çift tıklama-düzenleme davranışı Temmuz 2025’te Markdown editörüyle tanıtıldı ve şikayetler neredeyse hemen başladı.

Yayılım durumu

Bu zaten bir müşteri alt kümesine yayılıyor ve önümüzdeki iki ila üç hafta içinde herkese genişleyecek.

Bookmark Studio, Visual Studio Yer İşaretlerine Slot Tabanlı Gezinti ve Paylaşım Getiriyor

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

Visual Studio’daki yer işaretleri her zaman… idare ederdi. Bir tane koyarsınız, bir sonrakine geçersiniz, hangisinin ne olduğunu unutursunuz. Çalışırlar, ama hiçbir zaman güçlü diyebileceğiniz bir özellik olmadılar.

Mads Kristensen, eğer yer işaretlerini düzenli kullanıyorsanız muhtemelen karşılaştığınız boşlukları tam olarak dolduran deneysel bir uzantı olan Bookmark Studio’yu yayımladı.

Slot tabanlı gezinti

Temel yenilik şu: yer işaretleri artık 1–9 numaralı slotlara atanabilir ve doğrudan Alt+Shift+1 ile Alt+Shift+9 tuş kombinasyonlarıyla erişilebilir. Yeni yer işaretleri otomatik olarak bir sonraki boş slotu alır; dolayısıyla çoğu durumda herhangi bir yapılandırma gerektirmeden hızlı gezinti çalışır.

Bu basit görünüyor, ama yer işaretlerini “bir yerlerde bazı yer işaretlerim var” durumundan “Slot 3 API controller’ım, Slot 5 servis katmanı, Slot 7 test” haline getiriyor. Bu tür uzamsal bellek, odaklanılmış çalışma oturumlarında gezintiyi neredeyse anında yapıyor.

Yer İşareti Yöneticisi

Yeni bir araç penceresi, tüm yer işaretlerinizi tek bir yerde ad, dosya, konum, renk veya slota göre filtreleme seçeneğiyle gösteriyor. Herhangi bir yer işaretine atlamak için çift tıklayabilir ya da klavyeyle gezinebilirsiniz.

Eğer hiç beş-altı yer işaretinden fazlasına sahip olup hangisinin ne olduğunu takip edemediğiniz olduysa, bu tek başına uzantıyı kurmaya değer.

Etiketler, renkler ve klasörlerle organizasyon

Yer işaretlerine isteğe bağlı olarak etiket ve renk eklenebilir, klasörlere gruplandırılabilir. Bunların hiçbiri zorunlu değil — mevcut yer işareti iş akışınız çalışmaya devam eder. Ancak karmaşık bir sorunu hata ayıkladığınızda ya da tanıdık olmayan bir kod tabanını keşfettiğinizde, yer işaretlerinizi renklendirebilmek ve etiketleyebilmek yararlı bir bağlam katıyor.

Tüm meta veriler çözüm başına saklanır; dolayısıyla yer işareti organizasyonunuz oturumlar arasında kalıcı olur.

Dışa aktarma ve paylaşma

Bilmeden istediğim özellik bu. Bookmark Studio, yer işaretlerini düz metin, Markdown veya CSV olarak dışa aktarmanıza izin veriyor. Yani şunları yapabilirsiniz:

Pull request açıklamalarına yer işareti yollarını eklemek
İnceleme izlerini takım arkadaşlarıyla paylaşmak
Yer işareti kümelerini repolar veya dallar arasında taşımak

Yer işaretleri yalnızca kişisel bir gezinti aracı olmaktan çıkıp “işte bu kodun geçtiği yol” mesajını iletmenin bir yoluna dönüşüyor.

Kod hareketini izleyen yer işaretleri

Bookmark Studio, yer işaretlerini bağlandıkları metne göre takip eder; böylece düzenleme yaparken yanlış satırlara kaymazlar. Hiç bir hata ayıklama oturumunda yer işaretleri koyup bir yeniden yapılandırmanın ardından hepsinin yanlış satırlara işaret ettiğini gördüyseniz — bu durumu düzeltiyor.

Sonuç

Bookmark Studio hiçbir şeyi yeniden icat etmiyor. Yıllardır “yeterince iyi” olan bir özelliği alıp odaklanılmış geliştirme için gerçekten kullanışlı hale getiriyor. Slot gezintisi, Yer İşareti Yöneticisi ve dışa aktarma özellikleri öne çıkanlardır.

Visual Studio Marketplace‘dan indirin ve deneyin.

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.

Dizüstü Bilgisayardan Üretime: İki Komutla AI Agent'larını Microsoft Foundry'ye Dağıtma

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

“Makinemde çalışıyor” ile “dağıtıldı ve trafik sunuyor” arasındaki o boşluğu bilirsiniz? AI agent’ları için bu boşluk acı verici derecede geniş oldu. Kaynak sağlamanız, modelleri dağıtmanız, kimliği bağlamanız, izlemeyi kurmanız gerekiyor — ve bütün bunlar herhangi biri agent’ınızı çağırabilmeden önce.

Azure Developer CLI bunu iki komutluk bir iş haline getirdi.

Yeni `azd ai agent` iş akışı

Bunun gerçekte nasıl göründüğünü anlatalım. Bir AI agent projeniz var — diyelim ki bir otel danışman agent’ı. Yerel olarak çalışıyor. Microsoft Foundry üzerinde çalışmasını istiyorsunuz.

azd ai agent init
azd up

Hepsi bu. İki komut. azd ai agent init, reponuzda altyapı-kod olarak iskele oluşturur ve azd up her şeyi Azure’da sağlayıp agent’ınızı yayımlar. Foundry portalında agent’ınıza doğrudan bir bağlantı alırsınız.

Arka planda ne oluyor

init komutu reponuzda gerçek, incelenebilir Bicep şablonları oluşturuyor:

Bir Foundry Kaynağı (üst düzey kapsayıcı)
Bir Foundry Projesi (agent’ınızın bulunduğu yer)
Model dağıtımı yapılandırması (GPT-4o vb.)
Uygun RBAC rol atamalarıyla Yönetilen kimlik
Servis haritası için azure.yaml
Agent meta verileri ve ortam değişkenleriyle agent.yaml

İşte kilit nokta: bunların hepsi size ait. Reponuzda sürümlendirilmiş Bicep. İnceleyebilir, özelleştirebilir ve agent kodunuzun yanı sıra commit edebilirsiniz. Sihirli kara kutular yok.

Geliştirme döngüsü

Gerçekten beğendiğim şey yerel geliştirme hikayesi. Agent mantığını geliştirirken, her prompt değişikliğinde yeniden dağıtmak istemezsiniz:

azd ai agent run

Bu, agent’ınızı yerel olarak başlatır. Bunu test promptları göndermek için azd ai agent invoke ile eşleştirin, sıkı bir geri bildirim döngüsü elde edersiniz. Kodu düzenleyin, yeniden başlatın, çağırın, tekrarlayın.

invoke komutu yönlendirme konusunda da akıllı — yerel bir agent çalışırken otomatik olarak onu hedefler. Çalışmıyorken uzak endpoint’e isabet eder.

Gerçek zamanlı izleme

Bu beni ikna eden özellik. Agent’ınız dağıtıldığında:

azd ai agent monitor --follow

Agent’ınızdan geçen her istek ve yanıt gerçek zamanlı olarak terminalinize akıyor. Üretim sorunlarını hata ayıklamak için bu paha biçilmez. Log analitiğini karıştırmak yok, metriklerin toplanmasını beklemek yok — şu an ne olduğunu görüyorsunuz.

Tam komut seti

İşte hızlı referans:

Komut	Ne yapıyor
`azd ai agent init`	IaC ile bir Foundry agent projesi iskele oluşturur
`azd up`	Azure kaynaklarını sağlar ve agent’ı dağıtır
`azd ai agent invoke`	Uzak veya yerel agent’a prompt gönderir
`azd ai agent run`	Geliştirme için agent’ı yerel olarak çalıştırır
`azd ai agent monitor`	Yayımlanan agent’dan gerçek zamanlı logları akıtır
`azd ai agent show`	Agent sağlığını ve durumunu kontrol eder
`azd down`	Tüm Azure kaynaklarını temizler

.NET geliştiricileri için neden önemli

Duyuruda örnek Python tabanlı olsa da, altyapı hikayesi dilden bağımsız. .NET agent’ınız aynı Bicep iskeleleme, aynı yönetilen kimlik kurulumu, aynı izleme pipeline’ı alıyor. .NET Aspire uygulamalarınız veya Azure dağıtımları için zaten azd kullanıyorsanız, bu mevcut iş akışınıza tam oturuyor.

AI agent’ları için dağıtım boşluğu, ekosistemdeki en büyük sürtüşme noktalarından biri oldu. Çalışan bir prototipi uygun kimlik, ağ ve izlemeyle bir üretim endpoint’ine götürmek bir haftalık DevOps çalışması gerektirmemeli. Artık iki komut ve birkaç dakika gerektiriyor.

Sonuç

azd ai agent şu an mevcut. AI agent’larınızı dağıtmayı erteliyorsanız çünkü altyapı kurulumu çok fazla iş gibi geliyordu, bunu bir deneyin. Ön uç sohbet uygulaması entegrasyonu dahil adım adım tam kılavuz için tam anlatıma göz atın.

Developer-Tools | The .NET Blog

Azure MCP Server Artık .mcpb — Herhangi Bir Runtime Olmadan Yükle

MCP Bundle Nedir?

Nasıl Kurulur

Başlamak için

VS Code 1.118: Copilot CLI Oturum Adları, Model Rozetleri ve TypeScript 7.0 Nightly Alıyor

Copilot CLI: Oturumlara Gerçek Adlar Geliyor

Klavye Kısayollarıyla Hızlı Oturum Değiştirme

Sohbette Model Rozetleri

Copilot CLI’da Otomatik Model Seçimi

TypeScript 7.0 Nightly Katılımı

Foundry Toolboxes: Tüm Ajan Araçları için Tek Bir Endpoint

Toolbox nedir?

Dört sütun (bugün ikisi mevcut)

Pratik örnek

Foundry Agents’a bağımlılık yok

Neden şimdi önemli?

Sonuç

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

VS Code 1.117: Agentlar Artık Kendi Git Dallarını Alıyor ve Ben Bunun İçin Buradayım

Autopilot modu artık tercihinizi hatırlıyor

Agent oturumları için worktree ve git izolasyonu

Alt-agentlar ve agent ekipleri

Agentlar girdi gönderdiğinde terminal çıktısı otomatik dahil ediliyor

macOS’ta Agents uygulaması kendi kendini güncelliyor

Bilmeye değer küçük şeyler

Sonuç

Docker Sandbox, Copilot Agent'larının Makinenizi Tehlikeye Atmadan Kodunuzu Yeniden Düzenlemesini Sağlıyor

Docker Sandbox size gerçekte ne veriyor

.NET geliştiricilerinin neden önemsemesi gerekiyor

Güvenlik boyutu önemli

Sonuç

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

Azure MCP Araçları Artık Visual Studio 2022'ye Entegre — Uzantı Gerekmiyor

Bu aslında ne anlama geliyor

Bu neden göründüğünden daha önemli

Bununla neler yapabilirsiniz

Nasıl etkinleştirilir

Bir not

Büyük resim

azd update — Tüm Paket Yöneticileriniz İçin Tek Bir Komut

Nasıl çalışıyor

Küçük bir uyarı

Neden önemli

.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

O Visual Studio Kayan Pencere Ayarını Hiç Duydunuz mu? (Duymanız Gerekiyor)

Ayar nerede?

Çoklu monitör kurulumlarında neden “None” doğru seçim?

Hızlı öneriler

Çözüm: `--isolated`

CSS `@import` bağlantı çözümlemesi

Yeni `azd ai agent` iş akışı