SDK-style geçişi zorunlu mu? Eski projelerim çalışmaya devam eder mi?

Hayır, zorunlu değil. Microsoft eski MPF tarzı projelerin desteğini kesmiyor, yani aslında sadece modern bir alternatif sunuyor. Eski eklentileriniz Visual Studio 18.5 ve sonrasında da sorunsuz çalışıyor (en azından benim deneyimim böyle). Ama bence yeni geliştirmeler için SDK-style'a geçmekte kesinlikle fayda var.

Build süresinde gerçekten %75 iyileşme görür müyüm?

İşin garibi, Bu rakam Microsoft'un iç verilerinden geliyor (evet, doğru duydunuz). Büyük çözümler için geçerli — mesela küçük, tek alt projelik değişikliklerde bu farkı pek göremezsiniz. Ama 10+ projeli, 100K+ satırlık bir solution'da fark gerçekten dramatik oluyor. Açıkçası kendi ortamınızda önce ölçüm yapmanızı öneririm, sonuçlar durumdan duruma çok değişiyor.

VisualStudio.Extensibility ile VSSDK arasındaki fark ne?

VSSDK, hani klasik ve derinlemesine entegrasyon sağlayan eski framework — ama in-process çalışıyor ve IDE'yi yavaşlatabiliyor. VisualStudio.Extensibility ise daha modern ve out-of-process çalışan yeni framework. Çok daha güvenli, yani bir şeyler patlarsa IDE'yi çökertmiyor (ki bu çoğu kişinin gözünden kaçıyor). Ama hâlâ tüm VSSDK API'lerini karşılamıyor. Tecrübeme göre karmaşık eklentilerde hâlâ VSSDK'ya ihtiyaç duyuyorsunuz.

CI/CD pipeline'ımı değiştirmem gerekecek mi?

Genelde hayır. SDK-style projeler zaten standart dotnet build ya da msbuild komutlarıyla derleniyor. Yani büyük bir değişiklik yok. Sadece MSBuild sürümünüzün VS Build Tools 18.5+ olduğundan emin olun — bazı eski Azure DevOps agent image'ları güncelleme isteyebilir.

vsixmanifest designer'ını kaybettim, ne yapacağım?

Aslında kaybolmadı, sadece varsayılan editör değişti. Solution Explorer'da vsixmanifest dosyasına sağ tıklayıp "Open With" seçeneğinden klasik designer'ı seçebilirsiniz (ben de ilk duyduğumda şaşırmıştım). Ama benim tavsiyem şu: XML editörüne alışın. Hem çok daha hızlı, hem de git diff'lerinde çok daha temiz görünüyor.

VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor

⏱️ 8 dk okuma📅 3 Mayıs 2026🔄 Güncelleme: 15 Temmuz 2026

Visual Studio extension geliştirenler için biraz nostaljik bir yerden başlayayım. Hatırlarım, 2017 civarıydı sanırım, bir müşteri için özel bir Visual Studio eklentisi yazıyorduk. Küçücük bir değişiklik yapıyorsun, F5’e basıyorsun, çayı koyuyorsun, dönüyorsun — build hâlâ sürüyor. Sabır testi gibi bir şeydi. Şimdi 18.5 sürümüyle birlikte Microsoft, VSSDK tabanlı eklentiler için resmî SDK-style proje desteğini duyurdu ve açıkçası bu, uzun zamandır beklenen bir adım.

📋 İçindekiler

1. Visual Studio 18.5’i kurun: Visual Studio extension development workload’u ile birlikte.Insiders sürümünden başlayabilirsiniz.
2. Pilot proje seçin: En basit,en az bağımlılığı olan eklentinizi seçin.Hemen production eklentinize dalmayın.
3. Yeni boş bir SDK-style VSIX projesi oluşturun: Sonra csproj yapısını inceleyin.Hangi property nereye gidiyor görün.
4. Migrasyonu bir branch’te yapın: Eski csproj’un yedeğini saklayın.Mads’in örnek PR’ı burada iyi referans oluyor.
5. Build sürelerini ölçün: Geçişten önce ve sonra bakın.Sayısal veri olmadan iyileşmeyi anlatmak zor oluyor.
6. CICD pipeline’ınızı test edin: Mesela YAML tabanlı pipeline kullanıyorsanız MSBuild argümanları değişebilir.
Bir şey daha ekleyeyim:ilk denemede beklediğiniz hızı görmeyebilirsiniz.Bende ilk build aynı sürede tamamlanmıştı mesela.İkinci,üçüncü incremental build’lerde fark belirginleşti.FUTDC mekanizması sanki biraz alışma süreci geçiriyor gibi — projeyi tanıdıkça hızlanıyor.Bu aradaVisual Studio 2026 Insiders 3’te TypeScript 7 Beta Varsayılanw yazımda da benzer build optimizasyon konularına değinmiştim,ilgilenen bakabilir.

Karlaşabileceğınız Tipik Sorunlar

Pekâlâ,geçen ay bir müşteride yaptığım migration sırasında karşılaştığım birkaç şeyi not düşeyim:Birincisi,eski projedeki /Resources.resx` dosyalarının auto-generation'ı bazen bozuluyor. Çözüm basit sayılır:designer.cs dosyasını silip Visual Studio'nun yeniden generate etmesini beklemek. İkincisi,signed assembly kullanıyorsanız strong name key path'i otomatik bulunamıyor — manuel olarak `<AssemblyOriginatorKeyFile>` eklemeniz gerekiyor.

Üçüncüsü işe biraz tuhaftı:pkgdef dosyalarının generate edilmediğini fark ettim. Saatlerce kurcaladıktan sonra `<GeneratePkgDefFile>` property’sının `true` olması gerektiğini gördüm. Şablonda vardı aslında. Migration sırasında düşmüş.Bu yüzden migration sonrası şablon dosyayla satır satır karşılaştırma yapmanızı öneririm: Tam da burada iş uzuyor zaten.」
Sıkça Sorulan Sorular SDK-style geçişi zorunlu mu? Eski projelerim çalışmaya devam eder mi? Hayır, zorunlu değil. Microsoft eski MPF tarzı projelerin desteğini kesmiyor, yani aslında sadece modern bir alternatif sunuyor. Eski eklentileriniz Visual Studio 18.5 ve sonrasında da sorunsuz çalışıyor (en azından benim deneyimim böyle). Ama bence yeni geliştirmeler için SDK-style'a geçmekte kesinlikle fayda var. Build süresinde gerçekten %75 iyileşme görür müyüm? İşin garibi, Bu rakam Microsoft'un iç verilerinden geliyor (evet, doğru duydunuz). Büyük çözümler için geçerli — mesela küçük, tek alt projelik değişikliklerde bu farkı pek göremezsiniz. Ama 10+ projeli, 100K+ satırlık bir solution'da fark gerçekten dramatik oluyor. Açıkçası kendi ortamınızda önce ölçüm yapmanızı öneririm, sonuçlar durumdan duruma çok değişiyor. VisualStudio.Extensibility ile VSSDK arasındaki fark ne? VSSDK, hani klasik ve derinlemesine entegrasyon sağlayan eski framework — ama in-process çalışıyor ve IDE'yi yavaşlatabiliyor. VisualStudio.Extensibility ise daha modern ve out-of-process çalışan yeni framework. Çok daha güvenli, yani bir şeyler patlarsa IDE'yi çökertmiyor (ki bu çoğu kişinin gözünden kaçıyor). Ama hâlâ tüm VSSDK API'lerini karşılamıyor. Tecrübeme göre karmaşık eklentilerde hâlâ VSSDK'ya ihtiyaç duyuyorsunuz. CI/CD pipeline'ımı değiştirmem gerekecek mi? Genelde hayır. SDK-style projeler zaten standart dotnet build ya da msbuild komutlarıyla derleniyor. Yani büyük bir değişiklik yok. Sadece MSBuild sürümünüzün VS Build Tools 18.5+ olduğundan emin olun — bazı eski Azure DevOps agent image'ları güncelleme isteyebilir. vsixmanifest designer'ını kaybettim, ne yapacağım? Aslında kaybolmadı, sadece varsayılan editör değişti. Solution Explorer'da vsixmanifest dosyasına sağ tıklayıp "Open With" seçeneğinden klasik designer'ı seçebilirsiniz (ben de ilk duyduğumda şaşırmıştım). Ama benim tavsiyem şu: XML editörüne alışın. Hem çok daha hızlı, hem de git diff'lerinde çok daha temiz görünüyor. Kaynaklar ve İleri Okuma SDK-Style Support for Extension Projects — Visual Studio Blog Visual Studio SDK Resmi Dokümantasyonu Örnek Migration PR — Mads Kristensen / SelectedWhitespace Eh, VisualStudio.Extensibility Framework Dokümantasyonu

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.
Aşkın KILIÇYazar
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102
İlgili Yazılar
Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede?5 Nis 2026
Visual Studio'da GitHub Copilot Haziran Güncellemesi15 Tem 2026
C++ Kodunu CLI’da Anlamak: Copilot’a Gelen Akıllı Katman10 May 2026
Azure Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu?5 Nis 2026

Bu içerik işinize yaradı mı?

Benzer içerikleri kaçırmamak için YouTube ve GitHub hesaplarımı takip edin.

YouTube GitHub

Haftalık Bülten

Her pazar özenle seçilmiş teknoloji yazıları doğrudan e-postanıza gelsin.