Geçenlerde bir müşteri tarafında — bir sigorta şirketinin iç araç ekibinde — bir Visual Studio extension’ı ayakta tutmaya çalışıyorduk. 2017’den kalma, MPF tarzı (eski usul) bir VSIX projesi. Tek satır kod değiştiriyorum, build 47 saniye. İki satır değiştiriyorum, yine 47 saniye. Üç satır… tahmin edin? Yine 47 saniye.
Sebep belli aslında. Incremental build düzgün çalışmıyor; yanı küçük bir değişiklik yapınca sistem akıllıca davranmak yerine her şeyi baştan derliyor, bu da insanın sabrını baya zorluyor. Bu yazıyı yazmamın sebebi de tam burada yatıyor: Microsoft, Visual Studio 18.5 ile bu işe nihayet resmî bir çözüm getirdi ve VSIX projeleri için SDK-style proje desteği dedi.
Ve işler burada ilginçleşiyor.
Açık konuşayım, bu haberi ilk duyduğumda “geç de olsa” dedim içimden. Çünkü.NET tarafında SDK-style projeler 2017’den beri vardı, ama extension yazanlar hâlâ 200 satırlık csproj dosyalarıyla. MSBuild import zincirleriyle boğuşuyordu; hani ölür ya, iş küçük görünür ama her dokunuşta başka yerinden ses verir. Neyse uzatmayayım, ne değişti, kimi nasıl etkiler, migration nasıl yapılır — hepsine bakalım.
Önce Şunu Netleştirelim: SDK-Style Ne Demek?
Eski csproj dosyalarını görmüş olan bilir (kendi tecrübem). Sayfalar dolusu XML, her proje için ayrı <Compile Include="..."> satırları, GUID’ler, bir de o meşhur ProjectTypeGuids karmaşası… İnsan bakınca “bunu niye böyle yapmışlar?” diyor. SDK-style işe modern.NET dünyasında işimizi baya kolaylaştıran o kısa format; üstte <Project Sdk="Microsoft.NET.Sdk"> yazıyorsun, gerisini çoğu zaman convention hallediyor.
Çok konuştum, örnekle göstereyim.
Şahsen, VSSDK tarafında bunun eksik olması biraz garipti açıkçası. Çünkü Microsoft’un modern VisualStudio.Extensibility framework’ü zaten SDK-style ile geliyor, yanı out-of-process extension yazıyorsan düzen var, ama klasik in-process VSSDK kullanıyorsan hâlâ eski usule takılıyordun. Burada, peki neden? İşte bu çelişki artık kapanıyor gıbı görünüyor.
Önemli not: Mevcut MPF-tarzı extension’larınız çalışmaya devam edecek. Microsoft kimseyi zorla migrate etmiyor. Bu sadece resmî bir alternatif sunuyor — ben bunu yerinde buldum açıkçası, çünkü geriye dönük uyumluluk bozulursa işin tadı kaçıyor.
Build Süresinde %75 Azalma — Gerçekten mi?
Microsoft’un blog yazısında “büyük solution’larda %75’e varan iyileşme” diyordu. Açık konuşayım, ilk anda biraz pazarlama kokusu aldım. Hani ölür ya, rakam güzel durur ama sahada iş başka çıkar (ki bu çoğu kişinin gözünden kaçıyor). Yine de Fast Up-To-Date Check’i test edince, şey, o kadar da sallamıyorlarmış dedim.
Hmm, bunu nasıl anlatsamdı…
Olay basit gıbı görünüyor. Eski VSIX projelerinde MSBuild her seferinde “acaba bir şey değişti mi?” diye dosya zaman damgalarına bakıyor, dependency graph’i tekrar kuruyor, sonra da “yok, aynı taş aynı hamam” deyip kenara çekiliyor; ama bu küçük kontrol bile saniyeleri yiyor. Fast Up-To-Date Check işe bu kararı Visual Studio’nün içinde veriyor, MSBuild’i hiç çağırmadan. Bir nevi build’in “evde mısın?” yoklaması gıbı. Kısa sürüyor, iş görüyor.
Kendi test senaryomda — orta büyüklükte 4 projeli bir VSIX solution’ında — rakamlar şöyle çıktı. Bakınca insanın kaşı kalkıyor biraz.
| Senaryo | MPF (Eski) | SDK-Style |
|---|---|---|
| Clean build | 42 sn | 38 sn |
| Tek dosya değişikliği rebuild | 31 sn | 7 sn |
| No-op build (hiç değişiklik yok) | 12 sn | < 1 sn |
| F5 deploy | ~50 sn | ~14 sn |
Bunu yaşayan biri olarak söyleyeyim, Clean build tarafında fark çok uçmuyor, normal. Ama asıl hikâye incremental build’de bir düşüneyim… dönüyor; yanı kodu yaz, F5’e baş, sonucu gör, geri dön… günün büyük kısmı böyle akıyor zaten (buna dikkat edin). Bu döngüde kazanç baya hissediliyor. Günde 50 kez F5’e basıyorsanız, bu fark birikiyor; hem de sessiz sedasız birikiyor.
Peki Bu Hız Nereden Geliyor?
Size bir şey söyleyeyim, İki yerden geliyor. Birinçisi az önce lafı geçen Fast Up-To-Date Check. İkincisi işe up-to-date deployment logic — yanı VS, VSIX’i deploy ederken artık “bu dosyayı zaten kopyalamıştım, tekrar uğraşmayayım” diyebiliyor. Eskiden her F5’te experimental hive neredeyse baştan doluyordu; şimdi işe sadece değişen parçalar devreye giriyor. Küçük fark gıbı duruyor ama toplamda iyi toparlıyor.
Yeni csproj — Sadeliğin Zaferi
İşte yeni VSIX projesinin csproj’u. Sadece 20 satır, fena değil. Eskiden bu ekranda 200+ satır görürdünüz; bak şimdi, aynı iş daha az gürültüyle dönüyor, üstelik dosyaya bakınca neyin nereden geldiği de daha çabuk anlaşılıyor.
<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>Dikkat ederseniz ProjectTypeGuids yok. Compile Include listeleri de yok, iyi ki yok. Hatta Reference elementleri bile ortada görünmüyor — hepsi PackageReference üzerinden geliyor,. Iş biraz sadeleşmiş durumda. Bu csproj’a bakıp 5 saniyede ne yaptığını anlayabilirsiniz. E peki, sonuç ne öldü? Eskisinde işe 5 dakikada da tam çözemeyebilirdiniz, açık konuşayım.
Evet.
Bir de güzel tarafı şu: bu yapı, “ben her şeyi elle yazayım” kafasını biraz kenara itiyor. Şey gıbı düşünün, eski usul projelerde bir sürü XML satırı arasında kayboluyorduk ya, burada o kalabalık büyük ölçüde gitmiş. Siz ne dersiniz? Az önce sade dedim ama aslında en kritik nokta bu değil, asıl mesele bakım yükünün düşmesi.
Kısacası, peki neden? Çünkü proje dosyası uzadıkça hata aramak da uzuyor, insanın gözü yoruluyor ve küçük bir değişiklik bile gereksiz risk çıkarabiliyor. Burada işe temel ayarlar net duruyor (TargetFramework, Nullable, LangVersion), geri kalan paket işi de PackageReference ile akıyor. Yanı lafı gevelemeden söyleyeyim: okunabilirlik baya iş görüyor.
Hmm, bunu nasıl anlatsamdı…
Şöyle ki, Tam da öyle.
Yukarıda bahsettiğim o olay var ya, hani bir projeyi açıp “bu neydi şimdi?” diye iç çektiğiniz anlar… İşte onun panzehiri biraz böyle dosyalar oluyor. Çok süslü değil, iddialı hiç değil, ama elinize alınca “tamam ya, bunu yönetirim” hissi veriyor. Daha açık söyleyeyim, siz ne dersiniz? (en azından benim deneyimim böyle)
Migration: Mevcut Bir Extension’ı Nasıl Taşırsın?
Araya gireyim: Şimdi işin can sıkıcı ama asıl kısmı burası. Yeni proje açmak kolay, önü herkes yapıyor; asıl mesele 5 yıllık, 12 alt projeli, 30 bin satırlık bir extension’ı yerinden oynatmak. Microsoft da Mads Kristensen’in SelectedWhitespace extension’ını migrate edip bir örnek PR yayınlamış, ben de kendi tarafımdaki bir iç araçta aynı yolu yürüdüm, o yüzden aklımda kalan pürüzleri biraz dökeyim.
Çok konuştum, örnekle göstereyim.
1. csproj’u Sıfırdan Yazın, Yamamayın
İlk denemede ben de eski csproj’u kurcalayıp SDK-style’a çevirmeye çalışmıştım. Pek önermem, açık konuşayım. Eski dosyada işe yaramayan import’lar var, deprecated kalan şeyler var, bir de araya serpiştirilmiş gereksiz UsingTask’lar var; yeni bir SDK-style csproj oluşturup eski dosyadan sadece custom property’leri taşımak daha temiz gidiyor. On dakika fazla sürüyor gıbı duruyor ama sonunda elinizde daha az sürpriz kalıyor.
2. WPF Kullanıyorsan UseWpf’i Unutma
Tool window’un içinde XAML varsa, csproj’a şu satırı koyman gerekiyor:
<UseWpf>true</UseWpf>Bunu atlayınca build çoğu zaman geçiyor, sonra runtime’da XAML yüklenmiyor. Karşına “Element not found” gıbı saçma sapan bir hata çıkıyor. Bana 1.5 saat kaybettirdi bu olay; sizde de aynı çile olmasın diye buraya özellikle yazıyorum.
3. SLN/SLNX’te Deployable İşaretle
Tuhaf ama, Bu kısım biraz kritik, hani gözden kaçınca insanı sınır eden cinsten. SDK-style projelerde F5’e bastığınızda extension’ın experimental hive’a deploy edilmesi için solution dosyasında projeyi deployable olarak işaretlemeniz gerekiyor; yeni SLNX formatında iş daha derli toplu duruyor, eski SLN’de de yapılabiliyor. Biraz elle uğraştırıyor. Bu konuyla ilgili Copilot Cloud Agent %20 Daha Hızlı: Custom Image Etkisi yazımıza da göz atmanızı tavsiye ederim.
4. vsixmanifest Artık XML Editör’da Açılıyor
Eski designer artık varsayılan değil. “Open With” → “Vsix Manifest Designer” yoluyla hâlâ açabiliyorsunuz ama ben XML editör tarafını daha rahat buldum, çünkü değişiklikleri anında görüyorsun ve designer’ın bazen yarım yamalak yansıttığı şeylerle uğraşmıyorsun. Bu ne anlama geliyor? Hatırlarsınız, o ekran bazen insanı gereksiz yere oyalıyordu. Daha fazla bilgi için .NET 10’da API Versioning ve OpenAPI: Pratik Entegrasyon yazımıza bakabilirsiniz.
devenv /rootsuffix Exp /resetsettings. Eski deployment artıkları yeni build’i bozabiliyor.
Türkiye’deki Ekipler İçin Bu Ne Anlama Geliyor?
İşin garibi, Açık konuşayım, Türkiye’de in-house Visual Studio extension geliştiren ekip sayısı öyle aman aman fazla değil. Ama yok da diyemem. En çok da bankacılık. Telekom tarafında, kendi internal tooling’ını Visual Studio’ya bağlayan ekipler var; Logosoft’ta bir telekom müşterimizde de kendi billing platformları için custom code generator’ları VSIX olarak paketliyorlardı, işte o noktada hız kazancı direkt developer productivity’ye vuruyor.
Durun, bir saniye.
Bir de şu tarafı var. Türkiye’de pek çok yazılım evi hâlâ.NET Framework 4.x üstünde dönüyor, hani eski. Hâlâ iş gören sistemler var ya, tam onlar; VSIX’in target framework’ü net472 olduğu için bu ekiplerin build pipeline’larına zaten uyuyor, yanı migration için “önce.NET 8’e geçelim” gıbı bir ön şart çıkmıyor. Direkt çevirebiliyorsun.
Maliyet kısmına gelince — ki ben FinOps tarafında çalıştığım için kafam otomatik oraya kayıyor — bir senior developer’ın saatini ortalama 600-800 TL diye düşünelim. Günde build sürelerinden sadece 30 dakika kazanmak bile haftada 2.5 saat ediyor, yılda da 100+ saati buluyor; beş kişilik ekipte rakam baya büyüyor, şey gıbı duruyor ama değil aslında. Migration’a ayırdığın 1 günlük yatırımın 2 haftada geri dönmesi de bu yüzden çok uçuk gelmiyor.
Küçük Ekip vs Enterprise: Hangisi Migrate Etmeli?
Dürüst olmak gerekirse, Bence işin ayrımı aslında baya net. Kısa cevap bu. Ama dür, biraz açayım; çünkü ekip büyüdükçe aynı migration kararı bir anda “hadi geçelim” seviyesinden çıkıp, risk, test, pipeline. Geri dönüş planı gıbı şeylerle uğraştırıyor.
- 1-3 kişilik küçük ekip / hobby projesi: Hemen migrate edin. Risk düşük, kazanç fena değil. Zaten böyle projelerde çoğu zaman aşırı custom MSBuild logic ölmüyor, varsa da genelde tek tük bir şey çıkıyor.
- Orta büyüklükte (4-15 dev) ekip: Önce pilot bir extension seçin, önü taşıyın. 1-2 hafta gözlemleyin. Sorun çıkmazsa diğerlerini sıraya koyun; yanı topyekûn dalmak yerine kontrollü gitmek daha az baş ağrıtıyor. (bu kritik)
- Enterprise / regulated sektör (banka, sigorta, kamu): Acele etmeyin. Mevcut MPF projeleri çalışmaya devam edecek, burada panik yok. Ama yeni başlayan extension’larda kesinlikle SDK-style ile başlayın; eski olanları işe risk-fayda analizine göre planlayın, çünkü bazen teknik doğru olan şey operasyonel olarak uygun olmayabiliyor.
Evet.
Ha bu arada, eğer ekibinizde CI/CD pipeline’ı varsa (Azure DevOps, GitHub Actions falan), migration sonrası YAML tarafına da bakın. Eski pipeline’larda hardcoded MSBuild target’ları kalabiliyor ve SDK-style projede o target’lar başka işimde olabiliyor; işte o noktada “neden build kırıldı?” diye dakikalarca ekranı dik dik izliyorsunuz. Konuyla ilgili Azure DevOps Git Policy API: 10-15 Kat Hız Geldi yazımda DevOps tarafındaki performans iyileştirmelerinden bahsetmiştim, oradaki yaklaşım burada da iş görüyor açıkçası.
Karşılaştığım Sorunlar ve Çözümleri
Garip gelecek ama, Migration sırasında benim başıma gelenler var ya, az buz değil. Azure Cosmos DB Conf 2026: Notlarım, İzlenimlerim ve yazımızda bu konuya da değinmiştik.
Sorun 1: Build sırasında “VSIXSourceItem could not be found” hatası çıktı. Sebep de aslında baya basitmiş: eski projede manual eklenmiş bazı asset’ler SDK-style yapıda otomatik olarak yakalanmadı, yanı proje onları görmedi; çözüm olarak csproj’a explicit <Content Include="..." IncludeInVSIX="true" /> eklemek gerekti.
Doğrusu, Evet, ilk bakışta kafa karıştırıyor. Ama işin aslı şu: yeni yapı her şeyi eski alışkanlıklarla taşımıyor, bazı dosyaları açık açık söylemen lazım.
Sorun 2: F5 dediğimde extension experimental hive’a deploy ölüyordu ama yüklenmiyordu. Şimdi, peki neden? Manifest tarafında bir InstallationTarget uyumsuzluğu vardı; yeni VS versiyonlarında manifest’in Version="[17.0,19.0)" aralığını kullanması gerekiyor, eskisi gıbı [15.0,17.0) kalırsa yükleme ölmüyor.
Şey, bu kısım biraz sinsiydi. Çünkü deploy başarılı gıbı görünüyor, sonra extension ortada yok; insan önce debug ayarını suçluyor. Bazen suçlu olan direkt manifest oluyor.
Bakın, Sorun 3: Debug sırasında symbol’ler yüklenmiyordu. Sebep işe PDB dosyalarının artık farklı bir klasöre kopyalanmasıydı; <DebugType>portable</DebugType> ekleyince mesele çözüldü.
Tam da öyle. Küçük bir satır, büyük bir uğraşın önünü kesiyor.
Bence bu güncelleme doğru yönde atılmış bir adım. Ama henüz tam oturmuş değil — özellikle dependency injection senaryolarında bazı edge case’ler var, hani o “bende niye çalışmadı?” dedirten türden şeyler; üç ay sonraki 18.6 sürümüne kadar production-critical extension’ları migrate etmeyi ben şahsen ertelerim.
Eksik Bulduğum Yanlar
Doğrusu, Olumlu tarafını yeterince anlattım, şimdi biraz da küsur arayayım (ben de ilk duyduğumda şaşırmıştım). Bir kere dokümantasyon hâlâ zayıf, hatta işin can sıkıcı kısmı da bu; migration guide’ı bir blog yazısı ile bir GitHub PR’ına yaslamışlar, ama official docs.microsoft.com tarafında elinle tutacağın düzgün bir rehber yok. Enterprise ortamda bu ufak bir detay değil. Şirket içi onay süreçlerinde “resmî döküman nerede?” sorusu hemen geliyor.
İkinci eksik şu: Project upgrade tool yok..NET tarafında “try-convert” gıbı bir araç vardı ya, csproj’u otomatik çeviriyordu, iş baya rahatlıyordu; burada işe VSIX için işi elle toparlamak zorundasın. Açık konuşayım, Microsoft buna bir upgrade aracı eklerse migration adoption ciddi şekilde artar diye düşünüyorum. Burada, peki neden? Çünkü kimse aynı dönüşümü tekrar tekrar elle yapmak istemiyor (bizzat test ettim)
Üçüncü ve en sınır bozucu nokta da şu: VS 18.5 henüz preview. Yanı bu özelliği production’da kullanmak istiyorsan, biraz bekleyeceksin; genel kullanıma açılmasını görmek gerekiyor, o da büyük ihtimalle 2026’nın ortası civarı. Markdown Rehberi: GitHub’da Sıfırdan Profesyonel README’ye yazımda da değinmiştim, Microsoft tooling tarafında preview’dan GA’ya geçiş bazen uzuyor, bazen de beklediğinden daha çok sürpriz çıkarıyor.
İlk adımda ne yapardım?
Denemek istiyorsanız, ben olsam şöyle ilerlerdim:
- Visual Studio 18.5 Preview’u indirin — yan yana kurulabiliyor, yanı mevcut VS 17.x’i bozma derdi yok.
- “Visual Studio extension development” workload’unu kurun — bunu atlayınca template’ler gelmiyor, sonra insan boş boş ekrana bakıyor.
- Yeni bir VSIX Project açın — boş template ile başlayın, csproj’u kendi gözünüzle görün; çünkü bazen işin aslı orada çıkıyor. (bu kritik)
- Mevcut bir MPF extension’ınız varsa, önce onun kopyasını alın ve test branch’inde migrate etmeyi deneyin. Direkt main’e dokunmayın, açık konuşayım, sonra can sıkıyor.
- Build süresini ölçün — öncesiyle sonrasını karşılaştırın, böylece üst yönetime gösterecek somut iki sayı elinizde ölür.
Evet.
Ne yalan söyleyeyim, Neyse uzatmayalım, ilk denemede amaç ortalığı karıştırmak değil; küçük bir kurulumla başlayıp davranışı görmek daha mantıklı oluyor. Hani bazen yeni sürüm gelir, herkes heyecanlanır ama asıl mesele o heyecanın build süresine nasıl yansıdığıdır (veya yansıyıp yansımadığıdır), işte önü ölçmeden karar vermek pek sağlıklı ölmüyor — itiraf edeyim, beklentimin üstündeydi —
Peki neden? Çünkü elinizde veri olmazsa, “baya iyi gıbı” demekle kalırsınız. Iki build arasındaki farkı net görürseniz, migration işi gerçekten değer mi hemen anlarsınız. Siz ne dersiniz?
Sıkça Sorulan Sorular
Mevcut MPF tarzı extension’larım çalışmaya devam edecek mi?
Evet, kesinlikle. Microsoft bu güncellemede zorla migration dayatmıyor — eski projeleriniz hiçbir değişiklik yapmadan çalışmaya devam ediyor. SDK-style aslında sadece yeni bir seçenek olarak sunuldu. Eski format hâlâ destekleniyor, yanı panikleyip her şeyi değiştirmenize gerek yok.
SDK-style’a geçmek için hangı Visual Studio sürümü gerekiyor?
Visual Studio 18.5 ve sonrası gerekiyor. Şu an preview aşamasında. Açıkçası production ekipleri için GA sürümünü beklemenizi tavsiye ederim (inanın bana). Ama tooling değişikliklerini test etmek istiyorsanız preview’u yan yana kurabilirsiniz, hani bir zararı olmaz.
VisualStudio.Extensibility framework’ü ile farkı nedir?
Bak şimdi, VisualStudio.Extensibility — yanı yeni out-of-process framework — zaten SDK-style destekliyordu. Bu güncelleme işe klasik in-process VSSDK extension’ları için aynı modern build deneyimini getiriyor. Yanı iki framework artık aynı proje yapı standardını kullanıyor. Bence bu, uzun vadede tooling birliği açısından gerçekten değerli bir adım — itiraf edeyim, beklentimin üstündeydi —
Build sürelerindeki %75 iyileşme her projede gerçekleşiyor mu?
Hayır. Bu rakam büyük solution’larda küçük değişiklikler için geçerli. Mesela tek projeli, küçük bir extension’da clean build farkı çok az hissediyorsunuz. Ama 5+ projeli, paylaşılan kütüphaneleri olan büyük solution’larda incremental build’lerde tecrübeme göre gerçekten ciddi bir kazanç görüyorsunuz.
Migration ne kadar sürer?
Bağlı. Küçük bir extension için 1-2 saat yeterli. Orta büyüklükte, hani 3-5 alt projeli bir extension için yarım gün ayırın. Custom MSBuild logic’i olan büyük enterprise extension’larda işe 1-3 gün sürebiliyor. Bence en sağlıklısı önce pilot bir proje seçip oradan tecrübe edinmek.
Kaynaklar ve İleri Okuma
SDK-Style Support for Extension Projects (Visual Studio Blog) — Matt Clark’ın orijinal duyuru yazısı. Tüm teknik detaylar burada.
VisualStudio.Extensibility Resmî Dokümantasyonu — Yeni nesil out-of-process extension framework rehberi.
Mads Kristensen’in SelectedWhitespace Migration PR’ı — Gerçek bir extension’ın SDK-style’a nasıl çevrildiğini adım adım gösteren örnek.
Eh, Fast Up-To-Date Check Dokümantasyonu — Build hızlandırması mekanizmasının arkasındaki teknik detay (ciddiyim)
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.
