Visual Studio 2026 Turu: Workload'lar, .slnx, Solution Explorer ve Code Search

Sürüm notu: Bu yazıdaki komutlar .NET 10 SDK (Software Development Kit) 10.0.402 ve karşılaştırma için .NET 8 SDK 8.0.419 ile denenmiştir. Visual Studio 2026 (18.11) yalnız Windows'ta çalıştığı için bu IDE (Integrated Development Environment) bu makinede (macOS) çalıştırılmadı; Installer, Solution Explorer, Code Search ve 18.11 özellikleri Microsoft Learn'deki dokümanlardan ve resmi release notes'tan aktarıldı. .slnx ve .slnf ile ilgili bütün çıktılar gerçek dotnet koşularından.

Önce Tahmin Et

Bookstore repo'sundaki Bookstore.sln 71 satır; içi proje tipi ve proje başına GUID'ler (Globally Unique Identifier) ile her proje için ayrı Debug/Release eşlemeleriyle dolu. Ekipten biri Visual Studio 2026'da dosyayı .slnx'e çevirip commit'liyor. Ertesi sabah iki şey oluyor: eski bir release branch'ini build alan, üzerinde yalnız .NET 8 SDK'sı kurulu bir CI (Continuous Integration) agent'ı kırmızıya dönüyor; bir geliştiricinin makinesinde ise dotnet build hiç başlamadan hata veriyor. Sence iki hatanın sebebi aynı mı? Ve .slnx'e geçmek için Visual Studio'ya ihtiyacın var mı?

Bu yazıda Visual Studio 2026'yı bir .NET + Angular geliştiricisinin gözünden geziyoruz: Installer'da ne kurulmalı, yeni güncelleme modeli ne demek, .slnx ve solution filter dosyaları nasıl çalışıyor, Solution Explorer ve Code Search'ten nasıl daha fazla verim alınır, 18.11 ile ne geldi.

Installer: Workload, Component ve .vsconfig

Visual Studio Installer kurulumu workload'lar ve tek tek component'ler üzerinden yapar. Workload, bir senaryo için gereken component'lerin hazır paketidir. .NET + Angular ekibi için çoğu zaman tek bir workload yeter: "ASP.NET and web development" (Microsoft.VisualStudio.Workload.NetWeb). Açıklamasına göre ASP.NET Core, HTML (HyperText Markup Language), JavaScript ve Docker dahil container araçlarını getiriyor. WPF (Windows Presentation Foundation) ya da WinForms yapıyorsan ".NET desktop development" (Microsoft.VisualStudio.Workload.ManagedDesktop), Azure'a deploy ediyorsan "Azure development" (Microsoft.VisualStudio.Workload.Azure) eklenir. 18.4 ile JSON (JavaScript Object Notation) editor'ü Core Editor'ün içine taşındı; yalnız JSON düzenlemek için web workload'u kurmak artık gerekmiyor.

Ekipte "bende o template çıkmıyor" konuşmasını bitirmenin yolu, kurulumu dosyaya dökmek. Installer'da ürün kartındaki More > Export configuration seçeneği kurulu workload ve component'leri bir .vsconfig dosyasına yazar. Elle de yazılabilir:

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Workload.CoreEditor",
    "Microsoft.VisualStudio.Workload.NetWeb"
  ]
}

Bu dosyayı solution'ın kök klasörüne koyarsan, Visual Studio solution'ı açtığında eksik component'leri tespit eder ve kurmayı önerir. Yeni bir makinede ise edition'a ait bootstrapper ile kullanılır; dokümandaki komut vs_professional.exe --config "C:\myconfig.vsconfig" --passive --wait biçiminde. Var olan kuruluma component eklemek için update değil modify komutu gerekir; update yalnız kurulu olanları günceller. Dosyaya extension da eklenebilir, ama yalnız Visual Studio Marketplace'te yayınlanan extension'lar otomatik "eksik" tespitine girer.

VS 2022 ile Yan Yana ve Yeni Güncelleme Modeli

Visual Studio 2026, Visual Studio 2022 ile aynı makineye yan yana kurulabilir; her kurulumun major sürüm, edition ve güncelleme kanalı kombinasyonu benzersiz olmalı. Aynı mantıkla Stable kanaldaki Visual Studio'nun yanına Insiders kanalını da kurabilirsin. Dokümanın uyarısı önemli: extension'lar otomatik taşınmaz, çünkü hepsi uyumlu değildir.

Güncelleme modelindeki asıl değişiklik iki parça. Birincisi, Stable kanalda her ay bir feature update geliyor; sürüm numarası 18.<Minor>.<Servicing> biçiminde ve minor her ay bir artıyor (18.0 Kasım 2025, 18.11 Ekim 2026). İkincisi, Microsoft IDE'yi build araçlarından ayırdı: .NET SDK'sı, MSVC (Microsoft Visual C++) derleyicisi gibi toolset'lerin birden fazla sürümü kurulumda yan yana durabiliyor, sen IDE'yi her ay güncellerken projenin derleyicisini ya da SDK'sını kendi takviminle ilerletiyorsun. Microsoft'un planına göre yıllık sürümler her Kasım'da yeni .NET ile geliyor ve önceki yılın kurulumunu yerinde güncelliyor; Visual Studio 2022'deki gibi yan yana yeni bir ürün olarak değil.

.NET tarafında bu ayrımın pratik karşılığı, bir önceki yazıda gördüğümüz global.json: IDE ayda bir güncellense bile repo hangi SDK ile build alınacağını kendisi söyler.

.slnx: Yeni Solution Formatı

.NET 10 SDK'sında dotnet new sln varsayılan olarak .slnx üretiyor; bu Microsoft Learn'de breaking change olarak belgelenmiş bir davranış değişikliği. Eski formatı istersen dotnet new sln --format sln yazarsın. Farkı görmek için aynı üç projeyi önce eski formatta bir solution'a ekledik:

$ dotnet new sln -n Legacy --format sln
The template "Solution File" was created successfully.
$ dotnet sln Legacy.sln add src/Bookstore.Api src/Bookstore.Core tests/Bookstore.Tests
Project `src/Bookstore.Api/Bookstore.Api.csproj` added to the solution.
Project `src/Bookstore.Core/Bookstore.Core.csproj` added to the solution.
Solution ./Legacy.sln already contains project src/Bookstore.Core/Bookstore.Core.csproj.
Project `tests/Bookstore.Tests/Bookstore.Tests.csproj` added to the solution.
$ wc -l Legacy.sln
      71 Legacy.sln
$ sed -n "6,8p" Legacy.sln
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "src", "src", "{827E0CD3-B72D-47B6-A68D-7590B98EB39B}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Bookstore.Api", "src\Bookstore.Api\Bookstore.Api.csproj", "{1B832D7C-ADC7-4A7F-8717-A4C6EAFBC371}"

Üçüncü satırdaki uyarı da bilgi veriyor: API (Application Programming Interface) projesi Bookstore.Core'a referans verdiği için CLI (Command Line Interface) onu API projesiyle birlikte zaten eklemiş. Sonra Visual Studio olmadan, yalnız CLI ile çevirdik:

$ dotnet sln Legacy.sln migrate
.slnx file ./Legacy.slnx generated.
$ wc -l Legacy.slnx
      14 Legacy.slnx
$ cat Legacy.slnx
<Solution>
  <Configurations>
    <Platform Name="Any CPU" />
    <Platform Name="x64" />
    <Platform Name="x86" />
  </Configurations>
  <Folder Name="/src/">
    <Project Path="src/Bookstore.Api/Bookstore.Api.csproj" />
    <Project Path="src/Bookstore.Core/Bookstore.Core.csproj" />
  </Folder>
  <Folder Name="/tests/">
    <Project Path="tests/Bookstore.Tests/Bookstore.Tests.csproj" />
  </Folder>
</Solution>

71 satırdan 14 satıra indik ve hiçbir veri kaybolmadı: yeni formatta varsayılan olan her şey (proje tipinin GUID'i, her proje için Debug/Release eşlemesi) yazılmıyor. Pratik kazanç merge'te: iki kişi aynı anda solution'a proje eklediğinde eski formatta birbirine geçen GlobalSection blokları çakışırdı, şimdi çoğu zaman iki ayrı <Project> satırı eklenir. Doğrudan .NET 10 ile oluşturduğun bir solution ise Configurations bloğu bile içermiyor; boş hali yalnız <Solution> ve </Solution> satırlarından ibaret.

Visual Studio'da aynı işi Solution Explorer'da solution'a sağ tıklayıp Save As ile .slnx seçerek yaparsın; bu özellik Visual Studio 2022 17.14'te stable hale gelmişti.

Eski Araçlarla Uyumluluk

Önce Tahmin Et'teki ilk hatayı yeniden ürettik: aynı .slnx'i global.json ile .NET 8 SDK'sına sabitlenmiş bir klasörde açtık.

$ dotnet --version
8.0.419
$ dotnet sln Bookstore.slnx list
Invalid solution `Bookstore.slnx`. Expected file header not found.
$ dotnet build Bookstore.slnx
./old8/Bookstore.slnx(1,1): error MSB4068: The element <Solution> is unrecognized, or not supported in this context.

Build FAILED.

.NET CLI .slnx'i 9.0.200 SDK'sından beri tanıyor; .NET 8 SDK'sı dosyayı eski formatta bir solution sanıyor, başlığı bulamayınca da onu bir MSBuild proje dosyası gibi okumaya çalışıyor. Eski release branch'lerini build alan agent'ları ya 9.0.200 ve üstüne yükseltmen ya da o branch'lerde .sln'i tutman gerekiyor. IDE tarafında Visual Studio 2022 17.14 ile, Rider 2024.2'den beri .slnx açılabiliyor.

İkinci hata başka bir şey. dotnet sln migrate eski dosyayı silmiyor; klasörde hem .sln hem .slnx kalınca dosya adı vermeden çalışan komutlar hangisini kullanacağını bilemiyor:

$ dotnet build
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

Geçişi tek bir commit'te yap: .slnx'i ekle, .sln'i sil, CI script'lerindeki dosya adlarını güncelle.

Solution Explorer: Filtreler ve Solution Filter Dosyaları

Solution Explorer'ın araç çubuğu küçük ama işe yarar şeyler barındırıyor. Pending Changes Filter (Ctrl+[, P) yalnız değişiklik yaptığın dosyaları, aynı düğmenin açılır menüsü yalnız açık dosyaları gösterir; commit öncesi "neye dokundum" sorusunun en hızlı cevabı budur. Sync with Active Document (Ctrl+[, S) editördeki dosyayı ağaçta bulur. Arama kutusu (Ctrl+;) dosya adlarında, istersen dosya içeriğinde de arar. Bir klasöre sağ tıklayıp New Solution Explorer View dersen, yalnız o klasörü kök alan ikinci bir Solution Explorer penceresi açılır; src/Bookstore.Api ve Angular projesini iki ayrı pencerede tutmak için kullanışlı.

Yüz projelik bir solution'da asıl kazanç solution filter'dan gelir. Solution'ı File > Open'daki Do not load projects seçeneğiyle hiçbir projeyi yüklemeden açar, yalnız ihtiyacın olanları Reload Project ile yükler, sonra File > Save Solution As Filter ile bu durumu bir .slnf dosyasına kaydedersin. Dosya düz JSON:

{
  "solution": {
    "path": "Bookstore.slnx",
    "projects": [
      "src/Bookstore.Api/Bookstore.Api.csproj"
    ]
  }
}

Filtrede yalnız API projesi var, ama API Bookstore.Core'a referans veriyor. CLI bu dosyayı da build alabiliyor ve bağımlılığı atlamıyor:

$ dotnet build Bookstore.Api.slnf
  Bookstore.Core -> ./src/Bookstore.Core/bin/Debug/net10.0/Bookstore.Core.dll
  Bookstore.Api -> ./src/Bookstore.Api/bin/Debug/net10.0/Bookstore.Api.dll
Build succeeded.

Filtre bir projenin yerini değiştirdiğinde ise sessizce eskimez, gürültüyle kırılır. Solution'da olmayan bir projeyi gösteren bir filtre:

$ dotnet build Broken.slnf
./Bookstore.slnx : error MSB4025: The project file could not be loaded. Microsoft.Build.Exceptions.InvalidProjectFileException: Solution filter file at "./Broken.slnf" includes project "src/Bookstore.Web/Bookstore.Web.csproj" that is not in the solution file at "./Bookstore.slnx".

Projeyi taşıyan ya da yeniden adlandıran kişi repo'daki .slnf dosyalarını da güncellemeli. Solution'a sonradan eklenen projeler ise mevcut filtrede yüklenmemiş proje olarak görünür.

Code Search ve Feature Search

Visual Studio 2026'da All-In-One Search iki şeyi tek kutuda birleştiriyor. Code Search (Ctrl+P, Ctrl+, ya da Ctrl+T) dosya, type ve member arar; Ctrl+P kısayolu 18.0 ile geldi ve Visual Studio Code'dan (VS Code) gelenlerin elini rahatlatıyor. Feature Search (Ctrl+Q ya da Ctrl+Shift+P) ise menüleri ve ayarları arar: "format document" yazınca komutu, "hot exit" yazınca ayarı bulursun.

Code Search'te önek ve kısayollar aramayı daraltır: f: dosyalar (Ctrl+Shift+T), t: type'lar (Ctrl+1, Ctrl+T), m: member'lar (Alt+\), x: düz metin (Shift+Alt+F). Satıra gitmek de aynı kutudan: :39 açık dosyada 39. satıra, Order:43 Order.cs'in 43. satırına götürür; file(line,col) biçimi derleyici çıktısındaki konumu kopyalayıp yapıştırmayı kolaylaştırır. Kutuyu sorgusuz açarsan son gezdiğin dosyalar listelenir. 18.0'da preview olarak gelen Did You Mean, yanlış yazdığın ya da tam hatırlamadığın dosya adı için Copilot destekli bir öneri getiriyor; Tools > Options > GitHub > Copilot > Search altından kapatılabiliyor.

Bir uyarı: Code Search isim arar, semantik ilişki aramaz. "Bu method'u kim çağırıyor" sorusu Find All References'ın işidir; bu farkı bir sonraki yazıda üç IDE üzerinden ayrıntılı ele alıyoruz.

18.11 ile Gelenler

13 Ekim 2026'da çıkan 18.11 (October Update) küçük ama günlük kullanımı değiştiren birkaç şey getirdi. Release notes'tan, bir .NET geliştiricisine en çok dokunanları seçtim:

• Numaralı tab kısayolları: Ctrl+Numpad1'den Ctrl+Numpad9'a kadar, aktif gruptaki görünür tab'lere doğrudan geçiş. Tab'leri klavyeyle taşımak için Ctrl+Shift+PgUp ve Ctrl+Shift+PgDn, editör zoom'unu %100'e döndürmek için Ctrl+NumPad0.
• Hot Exit: Visual Studio'yu kapatıp açtığında açık dokümanlar, kaydedilmemiş değişiklikler ve pencere düzeni geri gelir. Varsayılan olarak açık değil; Tools > Options > Projects and Solutions > General altından açılıyor.
• Fonts and Colors artık birleşik ayarlar (Unified Settings) sisteminde; yaptığın değişiklik settings.json'a yansıyor. 18.0 ile başlayan yeni ayar deneyiminin bir adımı daha.
• Stop build on first failure: Build and Run ayarlarında opt-in. Bir proje hata verdiğinde build'in geri kalanı durdurulur; Microsoft kendi testlerinde hatadan sonraki bekleme süresinde %94 azalma ölçtüğünü yazıyor (vendor ölçümü).
• Git tarafında bir commit'i çalışma ağacıyla karşılaştırma ve çakışmaları toplu çözme (Keep All Current, Take All Incoming); Copilot tarafında Copilot SDK üzerine kurulu yeni chat deneyimi opt-in olarak geldi. AI (Artificial Intelligence) özellikleri dokuzuncu yazının konusu.

Üretimde Dikkat

.vsconfig'i repo'da tut ve gözden geçir. Gereksiz workload'lar kurulumu onlarca GB büyütür; sistem gereksinimleri sayfası kuruluma göre 2,5 GB ile 210 GB arası disk, tipik kurulum için 20 ile 50 GB öngörüyor. Ekipteki herkesin aynı workload setini kurması, "bende o proje yüklenmiyor" vakalarının çoğunu bitirir.

Güncellemeyi ekip olarak yönet. Aylık feature update iyi bir şey, ama bir ekipte üç farklı minor sürüm aynı anda dolaşırken bir analyzer uyarısı ya da bir template davranışı makineden makineye değişebilir. Professional ve Enterprise için LTSC (Long-Term Servicing Channel) seçeneği var; kurumsal ortamda hangi kanalı kullandığını bilinçli seç.

.slnx geçişini CI ile birlikte planla. Build agent'larının SDK sürümünü, solution dosya adını kullanan script'leri ve .slnf dosyalarını aynı değişiklikte güncelle. Gerçek ölçüm: .NET 8 SDK'sı .slnx'i hiç okuyamıyor.

Sık Düşülen Tuzaklar

Her şeyi kurmak. "Belki lazım olur" diye seçilen mobile, oyun ve C++ workload'ları disk, güncelleme süresi ve IDE başlangıcı olarak geri döner. Önce NetWeb ile başla, ihtiyaç oldukça .vsconfig'e ekle.

Extension uyumluluğunu kontrol etmeden güncellemek. Microsoft, Visual Studio 2022 extension'larının büyük çoğunluğunun 2026'da güncelleme olmadan çalışacağını söylüyor, ama "çoğunluk" senin kritik extension'ın olmayabilir. Yan yana kurulumda extension'lar otomatik taşınmaz; güncellemeden önce kritik extension'ları Insiders ya da ikinci bir makinede dene.

Migrate sonrası eski .sln'i bırakmak. Klasörde iki solution dosyası olduğu an dosya adı vermeyen her dotnet build MSB1011 ile durur.

Solution filter'ı unutmak. Projeyi taşıyan kişi .slnf'i güncellemezse filtreyi kullanan herkesin build'i MSB4025 ile kırılır.

Code Search'i referans aracı sanmak. Bir method adını Code Search'te bulmak, onu kimlerin çağırdığını bulmak değildir.

Küçük Bir Deneme

★☆☆ Elindeki bir repo'da dotnet sln migrate çalıştır, iki dosyanın satır sayısını karşılaştır ve eski .sln'i silip dotnet build'in hâlâ çalıştığını doğrula.

★★☆ Repo'na yalnız ihtiyaç duyduğun workload'ları içeren bir .vsconfig ve backend projelerini içeren bir .slnf ekle. Filtredeki bir projenin bağımlılığını filtreden çıkardığında dotnet build ne yapıyor?

★★★ CI pipeline'ına "repo kökünde birden fazla solution dosyası varsa ya da bir .slnf solution'da olmayan bir projeyi gösteriyorsa build'i kır" diyen bir adım ekle. İpucu: dotnet build <dosya>.slnf bunu senin yerine söylüyor.

Visual Studio'nun iskeletini gördük. Bir sonraki yazıda üç IDE'yi aynı masaya koyup navigasyon ve kısayolları karşılaştırıyoruz: Go to Definition'dan Find All References'a, multi-caret'ten keymap değiştirmeye kadar, Windows ve macOS kısayollarıyla birlikte.