VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor
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.
Açık konuşayım: bu güncelleme ilk bakışta “ee, ne var bunda” dedirtebilir. Ama detaya girince tablo değişiyor, özellikle büyük çözümlerde çalışan ekipler için ciddi bir nefes alma alanı var. Build süresinde %75’e varan azalma vaadi konuşuluyor. Hadi bakalım, işin aslı neymiş bir kurcalayalım.
Neden SDK-Style? Eski MPF Stilinin Derdi Neydi?
Eskiden VSIX projesi açınca önünüze serilen csproj dosyasına bakıp “bu kadar XML gerçekten şart mı?” diye düşündüğünüz olduysa yalnız değilsiniz. Ben düşündüm. MPF (Managed Package Framework) tarzı projeler,.NET dünyasının baya eski günlerinden kalma bir mirastı — sayfalarca import satırı, hard-coded GUID’ler, karmaşık target dosyaları… Yanı modern geliştiriciyi biraz ürküten her şey oradaydı.
İşte tam da bu noktada devreye giriyor.
SDK-style işe 2017’de.NET Core ile hayatımıza girdi. Daha sade, daha okunur, daha rahat. Bir <Project Sdk="Microsoft.NET.Sdk"> satırıyla başlıyor ve gerisini SDK kendisi toparlıyor. Şimdi aynı yapı, nihayet VSSDK tabanlı eklentiler için de resmî olarak destekleniyor. İyi haber bu.
Bir şeyi netleştireyim: Modern VisualStudio.Extensibility framework’ü zaten SDK-style destekliyordu. Ama klasik VSSDK tabanlı eklentiler — yanı çoğumuzun hâlâ kullandığı ve IDE’ye derinlemesine giren tip — şimdiye kadar biraz dışarıda kalmıştı. İşte o boşluk şimdi kapanıyor. Evet, tam da bu.
Build Performansındaki Sırrın Adı: Fast Up To Date Check
Açık konuşayım, Hız iyileşmesinin kaynağı tek bir şey değil aslında; birkaç parçanın yan yana gelmesiyle oluşuyor (bu beni çok şaşırttı). Bunların başında Fast Up To Date Check (FUTDC) geliyor. Visual Studio, projenin son build’den beri değişip değişmediğini MSBuild’i çağırmadan önce hızlıca kontrol ediyor. Değişmediyse hiç dokunmuyor. Bu ne anlama geliyor? Eski MPF projelerinde bu mekanizma düzgün çalışmıyordu; her seferinde MSBuild devreye giriyor, dosya zaman damgalarını tek tek yokluyordu.
Küçük bir detay: Bir de incremental deployment tarafı var. Önceden bir VSIX’i F5 ile deploy ettiğinizde deneysel hive’a (Experimental Instance) eklenti baştan kuruluyordu. Şimdi sadece değişen dosyalar gidiyor. Geçen ay Logosoft’ta bir DevOps eklentisi üzerinde çalışırken bunu baya net hissettim — küçük bir komut handler değişikliği için F5’ten debugger’a geçiş süresi yaklaşık 45 saniyeden 12 saniyeye düştü. Ciddi fark var.
Bir dakika — bununla bitmedi.
Yeni csproj Dosyası: 200 Satırdan 20 Satıra
Şimdi işin göze görünen kısmına gelelim. Yeni proje şablonuyla oluşan csproj şu kadar kısa:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<Nullable>enable</Nullable>
<LangVersion>14</LangVersion>
<!-- VSIX ayarları -->
<VSSDKBuildToolsAutoSetup>true</VSSDKBuildToolsAutoSetup>
<VsixDeployOnDebug>true</VsixDeployOnDebug>
<GeneratePkgDefFile>true</GeneratePkgDefFile>
</PropertyGroup>
<ItemGroup>
<ProjectCapability Include="CreateVsixContainer" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.14.40265" ExcludeAssets="runtime" />
<PackageReference Include="Microsoft.VSSDK.BuildTools" Version="18.5.38461" />
</ItemGroup>
</Project>Bir bakıma, küçük bir detay: Yirmi satır civarı (yanlış duymadınız). Hepsi bu kadar. Şimdi, eski MPF projelerinde bu kadar az şeyle VSIX ayağa kaldırmak hayaldi resmen. Üstelik ExcludeAssets="runtime" ile gereksiz runtime referansları da dışarıda bırakılıyor — temiz dürüyor.
İşin garibi, Bir de şu nokta var: ProjectCapability elementi sayesinde Visual Studio bu projeye özel davranışlar uygulayabiliyor. Yanı IDE proje türünü tanıyor, ona göre menüleri, item template’lerini, debug profillerini gösteriyor. Eskiden bunlar projectTypeGuids ile yapılıyordu, hatırlayanlar bilir, GUID dünyasında kaybolup gidiyordunuz.
“Bu güncelleme, VSIX dünyasını nihayet 2025’in geliştirici deneyimine yaklaştırıyor..NET ekosistemi yıllardır SDK-style ile yaşıyor; extension geliştirme tarafının bu kadar geç katılması bence biraz can sıkıcıydı. Ama geç olsun, güç olmasın.”
Mevcut Eklentilerim Bozulacak mı? Migration Hikâyesi
Burası en çok sorulan yer zaten. Hayır, mevcut MPF tarzı eklentileriniz çalışmaya devam edecek. Microsoft burada zorlama bir geçiş yapmıyor; sadece resmî bir SDK-style seçeneği sunuyor. İsterseniz geçersiniz, istemezseniz kalırsınız. Daha fazla bilgi için langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar yazımıza bakabilirsiniz. Daha fazla bilgi için Apple Watch’ta Token Taşıma: Entra External ID’de Yeni Dönem yazımıza bakabilirsiniz.
Çok konuştum, örnekle göstereyim.
Eh, Ama şunu da söyleyeyim: Eğer aktif geliştirilen bir eklentiniz varsa geçişe değer gibi dürüyor. Mads Kristensen’in SelectedWhitespace eklentisi için yapılan örnek migration’a baktım, baya temiz ilerlemişti. Yaklaşık 150 satırlık eski csproj, 25 satıra düşmüş durumdaydi diyeyim size benzer şekilde yazayım derken dağıtmayayım ama sonuç net: build süresi de iyileşmiş.
Geçiş sırasında akılda tutulması gereken birkaç nokta var:
- XAML kullanıyorsanız csproj’a
<UseWpf>true</UseWpf>eklemeyi unutmayın. Yoksa tasarımcı dosyalarınız derlenmez. — ciddi fark yaratıyor - Sln ya da yeni SLNX dosyanızda eklentinizi deployable olarak işaretlemeniz gerekiyor — yoksa F5’e bastığınızda deploy olmaz, sadece build alınır gider. Beni de ilk denemede bu yakalamıştı, “neden experimental instance’a gelmiyor” diye yarım saat oyalanmıştım. — bunu es geçmeyin
- vsixmanifest dosyaları artık varsayılan olarak XML editöründe açılıyor gibi düşünün. Eski designer hâlâ dürüyor ama “Open With” menüsünden seçmeniz gerekiyor. İlk anda tuhaf gelebilir ama XML editörü aslında daha seri. (bence en önemlisi)
- Eğer projeniz çok sayıda custom build target içeriyorsa bunları yeni yapıya taşımak biraz vakit alabilir. Acele etmeyin.
Hangi Senaryoda Geçmeli, Hangisinde Beklemeli?
| Senaryo | Önerim |
|---|---|
| Yeni eklenti başlatıyorum | SDK-style ile başla, hiç düşünme |
| Aktif geliştirilen büyük eklenti | Bir feature branch’te dene, performans farkını ölç |
| Maintenance modunda eski eklenti | Acelesi yok, beklersin de olur |
| CICD pipeline’ı karmaşık | Önce build sunucularını test et, sonra geç |
| Çok sayıda custom MSBuild target var | Detaylı planlama gerek, tek seferde geçme |
Türkiye’deki Geliştirici Ekipleri Açısından Ne Anlama Geliyor?
Bi saniye — Bunu biraz Türkiye tarafından okumak istiyorum şimdi dehşet detaylara girmeden ama önemli kısmını atlamadan söyleyeyim. Bir bakıma, visual Studio extension geliştiren şirket sayısı bizde aslında sanıldığından az değil. Bankacılık tarafında özellikle kurum içi standartları zorlayan custom eklentiler çok yaygın — kod analizleri, naming convention check’leri, belirli framework’lere özel template’ler… Bir devlet bankasında çalışan eski bir meslektaşım anlatmıştı mesela,60+ developer’ı olan bir ekipte ortak bir VSIX kullanıyorlarmış ve build süreleri sürekli şikâyet konusuydu.
İşte bu güncelleme tam olarak bu tip ekipler için iyi oturuyor diyebilirim.Azure DevOps Git Policy Yönetimi: 10x Hız Kazanmanın Yolu yazımda da değinmiştim,kurumsal geliştirme ekiplerinde build/deployment hızındaki her saniye gün sonunda saatlere dönüşüyor.50 kişilik bir ekipte günde 10 build × 30 saniye tasarruf = haftada yaklaşık 12.5 saat.Bir kişi-gün’den fazla ediyor (inanın bana)
Küçük startup tarafında tablo başka.Ekip minikse muhtemelen zaten modern VisualStudio.Extensibility framework’üne yöneliyorlar,VSSDK’nın derinliklerine dalmak istemiyorlar.Onlar için bu güncelleme “iyi olmuş” seviyesinde kalıyor.Ama büyük kurumlarda,özellikle.NET Framework tabanlı legacy eklentilerle yaşamak zorunda olanlar için bu,uzun zamandır beklenen bir çıkış kapısı gibi. Daha fazla bilgi için Microsoft Discovery ile Ar-Ge’de Yeni Oyun: Agentic Yapılar yazımıza bakabilirsiniz.
Pratik Geçiş Rehberi: İlk Adım Olarak Ne Yapın?
Lafı gevelemeden,somut bir yol haritası bırakayım buraya: Run Dialog Yenilendi: Hız, Sadelik ve Güç Bir Arada yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor yazımıza bakabilirsiniz.
- Visual Studio 18.5’i kurun: Visual Studio extension development workload’u ile birlikte.Insiders sürümünden başlayabilirsiniz.
- Pilot proje seçin: En basit,en az bağımlılığı olan eklentinizi seçin.Hemen production eklentinize dalmayın.
- Yeni boş bir SDK-style VSIX projesi oluşturun: Sonra csproj yapısını inceleyin.Hangi property nereye gidiyor görün.
- Migrasyonu bir branch’te yapın: Eski csproj’un yedeğini saklayın.Mads’in örnek PR’ı burada iyi referans oluyor.
- Build sürelerini ölçün: Geçişten önce ve sonra bakın.Sayısal veri olmadan iyileşmeyi anlatmak zor oluyor.
- 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.
Karlaşabileceğı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
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder