JetBrains Rider ile .NET Geliştirme: Inspections, Decompiler, Database Tools ve Angular

Sürüm notu: Bu yazıdaki kodlar .NET 10 SDK (Software Development Kit) 10.0.402, Microsoft.EntityFrameworkCore.Sqlite 10.0.14 ve SQLite 3.54 ile derlenip denenmiştir. JetBrains Rider 2026.2 bu makinede (macOS) kurulu olmadığı için çalıştırılmadı; Rider'ın özellikleri, menü adları ve kısayolları (varsayılan Windows keymap'i) JetBrains'in Rider 2026.2 dokümanından ve resmi blog'undan aktarıldı. Database konsolunda yapılacak işi aynı SQL'i (Structured Query Language) sqlite3 komut satırında çalıştırarak gösterdik.

Önce Tahmin Et

Bookstore'da yavaşlayan bir sorgunun SQL'ini görmek istiyorsun. Entity Framework Core'dan (EF Core) ToQueryString() ile SQL'i alıyorsun, IDE'nin (Integrated Development Environment) database konsoluna yapıştırıp çalıştırıyorsun ki plan'ına bakasın. Sorgu fiyatı 40'tan büyük kitapları arıyor ve veritabanı SQLite. Sence EF'in ürettiği SQL, uygulamanın dışında, database aracında olduğu gibi çalışır mı?

Bu yazıda JetBrains Rider'ı bir .NET + Angular geliştiricisinin gözünden geziyoruz: ReSharper motoru ve ayar katmanları, decompiler ve Source Link, yerleşik database araçları, Angular için WebStorm özellikleri, dotUltimate araçları ve 2026.2'nin getirdikleri.

ReSharper Motoru ve Ayar Katmanları

Rider iki parçadan oluşur: IntelliJ platformu üzerine kurulu ön yüz ve C# analizini yapan ReSharper motorunun koştuğu bir backend process'i. Dördüncü yazıda gördüğümüz inspection'lar, quick-fix'ler ve Solution-Wide Error Analysis bu backend'den gelir; JavaScript, TypeScript ve SQL desteği ise IntelliJ platformunun WebStorm ve DataGrip'ten gelen parçalarından.

ReSharper kökenli ayarlar katmanlıdır. Dokümana göre ayar sayfalarının ikonundan hangi mekanizmanın kullanıldığını görürsün: ikonsuz sayfalar kullanıcı profilinde saklanan IDE ayarlarıdır, layer-based ayarlar ise "This computer", "Solution personal" ve "Solution team-shared" katmanlarına yazılır. Solution'a ait iki katman solution klasöründeki .DotSettings dosyalarında durur; team-shared olan repo'ya commit'lenir, personal olan commit'lenmez. Bu katmanlar ReSharper ile uyumludur, Visual Studio'da ReSharper kullanan ekip arkadaşıyla aynı inspection ayarlarını paylaşırsın. En önemli kural da dokümanda açıkça yazıyor: .editorconfig'te tanımlanan code style ve inspection ayarları bütün katmanları ezer. Ekip kuralını .editorconfig'e, ReSharper'a özgü ve .editorconfig'te karşılığı olmayan tercihleri team-shared katmana koymak çakışmayı önler.

Decompiler, Source Link ve Assembly Explorer

Bir NuGet paketinin ya da framework'ün içindeki method'a Go to Declaration (Ctrl+B) dediğinde Rider seni bir yere götürmek zorunda; nereye götüreceği ayarlara ve PDB (Program Database, sembol dosyası) bilgisinin varlığına bağlı. Rider'ın dört açık hedefi var: Assembly Explorer, Decompiled Sources, Metadata View ve Sources from Symbol Files. Varsayılan davranış Settings > Tools > External Symbols'tan seçilir.

Sources from Symbol Files, paketin PDB'sinde Source Link bilgisi varsa orijinal kaynak dosyayı derlemenin yapıldığı commit'ten indirir: yorumlar, gerçek değişken adları ve satır numaralarıyla. Source Link yoksa yerleşik decompiler IL'den (Intermediate Language) C# üretir; okunur, ama yorumlar ve yerel değişken adları yoktur, async method'lar ve LINQ (Language Integrated Query) sorguları derleyicinin ürettiği şekle yakın görünür. Assembly Explorer ise solution dışındaki herhangi bir assembly'yi açıp gezmeni sağlar. Debug sırasında aynı mekanizma çalışır: framework koduna step into yaptığında Rider decompile edilmiş ya da Source Link'ten gelen kaynakta durur. Source Link'in kendi projende nasıl üretildiğini Debugging serisinin beşinci yazısında gerçek çıktısıyla görmüştük.

Ne zaman işe yarar: bir kütüphanenin dokümanında yazmayan davranışı (ör. bir HttpClient handler'ının exception'ı neden yuttuğu) tahmin etmek yerine okumak için. Ne zaman yaramaz: decompile edilmiş kodu kopyalayıp kendi koduna yapıştırmak lisans açısından ayrı bir konudur; okumak için kullan.

Database Tools ile EF Core'un SQL'ini İncelemek

Rider'da DataGrip'in bütün özelliklerini sağlayan Database Tools and SQL plugin'i varsayılan olarak paketli ve açık; SQL Server, PostgreSQL, MySQL, SQLite ve diğerlerine bağlanır. Database penceresi varsayılan keymap'te Ctrl+W, X. Önce Tahmin Et'teki sorgu:

IQueryable<string> query = db.Books
    .Where(b => b.Price > 40m && b.Author.Name.StartsWith("Andrew"))
    .OrderBy(b => b.Title)
    .Select(b => b.Title);

// IDE'nin database konsoluna yapıştıracağın SQL
Console.WriteLine(query.ToQueryString());

SELECT "b"."Title"
FROM "Books" AS "b"
INNER JOIN "Authors" AS "a" ON "b"."AuthorId" = "a"."Id"
WHERE ef_compare("b"."Price", '40.0') > 0 AND "a"."Name" LIKE 'Andrew%'
ORDER BY "b"."Title"

The Pragmatic Programmer

Uygulamanın içinde sorgu çalıştı. Aynı SQL'i database aracına yapıştırınca:

$ cat query.sql
SELECT "b"."Title"
FROM "Books" AS "b"
INNER JOIN "Authors" AS "a" ON "b"."AuthorId" = "a"."Id"
WHERE ef_compare("b"."Price", '40.0') > 0 AND "a"."Name" LIKE 'Andrew%'
ORDER BY "b"."Title";
$ sqlite3 bookstore.db < query.sql
Parse error near line 1: no such function: ef_compare

Önce Tahmin Et'in cevabı: hayır. ef_compare, EF Core'un SQLite bağlantısına kendisinin kaydettiği bir fonksiyon; SQLite decimal tipini bilmediği için EF fiyatı metin olarak saklıyor ve karşılaştırmayı bu fonksiyonla yapıyor. Tablonun şeması bunu gösteriyor:

$ sqlite3 bookstore.db '.schema Books'
CREATE TABLE "Books" (
    "Id" INTEGER NOT NULL CONSTRAINT "PK_Books" PRIMARY KEY AUTOINCREMENT,
    "Isbn" TEXT NOT NULL,
    "Title" TEXT NOT NULL,
    "Price" TEXT NOT NULL,
    "AuthorId" INTEGER NOT NULL,
    CONSTRAINT "FK_Books_Authors_AuthorId" FOREIGN KEY ("AuthorId") REFERENCES "Authors" ("Id") ON DELETE CASCADE
);
CREATE INDEX "IX_Books_AuthorId" ON "Books" ("AuthorId");

Provider'a özgü fonksiyonu çıkarıp sorgunun geri kalanının plan'ına baktık; Rider'da database konsolundaki Explain Plan eylemi aynı bilgiyi tablo olarak verir:

$ cat plan.sql
EXPLAIN QUERY PLAN
SELECT "b"."Title"
FROM "Books" AS "b"
INNER JOIN "Authors" AS "a" ON "b"."AuthorId" = "a"."Id"
WHERE "a"."Name" LIKE 'Andrew%'
ORDER BY "b"."Title";
$ sqlite3 bookstore.db < plan.sql
QUERY PLAN
|--SCAN b
|--SEARCH a USING INTEGER PRIMARY KEY (rowid=?)
`--USE TEMP B-TREE FOR ORDER BY

Books tablosu baştan sona taranıyor (SCAN b) ve sıralama için geçici bir B-tree kuruluyor. Fiyat filtresi metin üzerinde bir fonksiyonla yapıldığı için bir index de yardımcı olmazdı. Bu bulgunun çözümü IDE'de değil modelde: EF Core serisinde decimal'ın provider'lara göre eşlenmesi ve index tasarımı yazıları bunun yeri. IDE'nin katkısı, uygulama kodundan çıkmadan SQL'i, şemayı ve plan'ı aynı pencerede görmek.

HTTP Client ve Endpoints Penceresi

Rider'da .http dosyalarını çalıştıran yerleşik bir HTTP (HyperText Transfer Protocol) Client var; editördeki istek satırının yanındaki çalıştır düğmesi isteği gönderir ve cevabı ayrı bir panelde gösterir. Endpoints penceresi (View > Tool Windows > Endpoints) ise projedeki istemci ve sunucu API'lerini (Application Programming Interface) HTTP ve WebSocket için toplu listeler, bir endpoint'in tanımına F4 ile gider; OpenAPI spesifikasyonları gibi dış kaynakları da ekleyebilirsin. .http dosyalarının sözdizimi ve Postman, Bruno gibi araçlarla karşılaştırması ilerideki API Araçları serisinin konusu.

Angular: WebStorm Özellikleri Rider'ın İçinde

Rider, WebStorm'un JavaScript, TypeScript ve Angular desteğini paketin içinde getirir; Visual Studio Code'daki (VS Code) gibi ayrı bir Angular extension'ı kurman gerekmez. Angular template'lerinde completion, navigasyon ve rename, component ile template arasında geçiş, ESLint ve Prettier entegrasyonu, package.json script'lerinden oluşturulan npm run configuration'ları ve JavaScript debugger'ı aynı IDE'de. Rider 2026.2, Go ile yeniden yazılan TypeScript 7 derleyicisini destekliyor; JetBrains kendi testinde büyük bir kod tabanında proje yükleme süresinin yaklaşık 12 saniyeden 3 saniyeye indiğini yazıyor (vendor ölçümü). Önceki yazıdaki compound configuration ile API ve Angular'ı tek tıkla debug edebilirsin.

Takas da var: Angular'ın kendi Language Service'i yerine JetBrains'in kendi Angular desteği çalışır. Yeni bir Angular özelliği (yeni template sözdizimi gibi) çıktığında desteği Rider'ın sürüm takvimine bağlıdır; Angular ekibinin VS Code extension'ı genelde Angular sürümüyle aynı gün güncellenir.

dotUltimate: dotTrace, dotMemory, dotCover

dotUltimate aboneliği Rider'ın yanında ReSharper, dotTrace (performance profiler), dotMemory (memory profiler), dotCover (code coverage) ve dotPeek'i (bağımsız decompiler) içerir; Rider'da profiler'lar ve coverage IDE'nin içinden başlatılır, sonuçlar editördeki koda bağlanır. Rider 2026.2, AI (Artificial Intelligence) agent'larının dotTrace snapshot'larını ve dotCover verisini okuyabildiği agent skill'leri de ekledi. Profiling'in yöntemi ve dotTrace ile Visual Studio Profiler karşılaştırması ilerideki .NET'te Profiling ve Diagnostics serisinin konusu; burada yalnız aletin nerede durduğunu bilmek yeterli.

Rider 2026.2 ile Gelenler

22 Temmuz 2026'da çıkan 2026.2'nin .NET geliştiricisine dokunan başlıkları, JetBrains'in sürüm duyurusundan:

• Performans: Windows'ta .NET uygulamalarında debugger yaklaşık 2,8 saniye daha hızlı başlıyor, Roslyn tabanlı solution'larda branch değiştirme genelde 2 ile 3 kat hızlı, backend process'leri yüzde 7 ile 8 daha az bellek kullanıyor (vendor ölçümleri).
• WPF (Windows Presentation Foundation) Hot Reload: Rider debugger'ı altında çalışan WPF uygulamasında XAML (Extensible Application Markup Language) değişiklikleri kaydedince yerinde uygulanıyor.
• Yeniden tasarlanan NuGet penceresi: arama, kurulu paketler ve güncellemeler ayrı yollara ayrıldı.
• C# file-based app template'i, intention preview'lar, yerleşik Azure Functions desteği ve Azure DevOps pull request penceresi.
• AI tarafında: GitHub Copilot'un agent seçicide yerleşik olarak gelmesi, Microsoft'un .NET, Aspire ve Azure agent skill'lerinin IDE'den kurulabilmesi ve Claude Code için derleme hatası varken agent'ın işi bitirmesini engelleyen kalite kontrol hook'ları. Dokuzuncu yazıda ayrıntılı.

File-based app'ler .NET 10'un özelliği; Rider'ın template'i yalnız oluşturmayı kolaylaştırıyor. Proje dosyası olmayan tek bir .cs dosyası, repo içi küçük araçlar için birebir:

#!/usr/bin/env dotnet
#:property Nullable=enable

// repo aracı: stoğu eşiğin altındaki kitapları listele
int threshold = args.Length > 0 ? int.Parse(args[0]) : 5;
(string Isbn, int Quantity)[] stock = [("978-0135957059", 3), ("978-0132350884", 12), ("978-0201616224", 0)];

foreach ((string isbn, int quantity) in stock.Where(s => s.Quantity < threshold))
{
    Console.WriteLine($"{isbn}: {quantity}");
}

$ dotnet run low-stock.cs -- 5
978-0135957059: 3
978-0201616224: 0
$ dotnet run low-stock.cs -- 1
978-0201616224: 0
$ chmod +x low-stock.cs
$ ./low-stock.cs 4
978-0135957059: 3
978-0201616224: 0
$ dotnet project convert low-stock.cs
$ ls low-stock
low-stock.cs
low-stock.csproj

Araç büyüyüp gerçek bir projeye dönüşmesi gerektiğinde dotnet project convert onu yanına bir .csproj ile klasöre taşıyor.

Üretimde Dikkat

Büyük solution'larda bellek ayarı. Rider'ın ön yüzü JVM (Java Virtual Machine) üzerinde çalışır; varsayılan JVM seçenekleri kurulum klasöründe durur ve doküman o dosyayı değiştirmemeni söyler, çünkü güncellemede ezilir ve macOS'ta uygulama imzasını bozar. Doğru yol Help > Edit Custom VM (Virtual Machine) Options ile yapılandırma klasöründe bir kopya oluşturmak ya da Help > Change Memory Settings. Backend process'inin ayrı bir bellek tüketimi olduğunu, SWEA'nın (Solution-Wide Error Analysis) büyük solution'larda ikisini birden büyüttüğünü unutma.

Team-shared katmanı kod gibi gözden geçir. .DotSettings dosyası XML (Extensible Markup Language) ve elle okunması zor; bir inspection'ı "Do not show" yapan bir değişiklik pull request'te tek satırlık masum bir diff gibi görünür.

Decompiler ve Source Link ağ ister. Kapalı bir kurumsal ağda symbol server'a ve kaynak sunucusuna erişim yoksa Rider decompiler'a düşer; bu normaldir, ama gördüğün kodun orijinal kaynak olmadığını bil.

Sık Düşülen Tuzaklar

Team-shared ve personal katmanları karıştırmak. Kişisel bir tercihi team-shared katmana kaydetmek, bütün ekibin inspection'larını değiştirir; ekip kararını personal katmana kaydetmek ise yalnız senin makinende geçerli kalır. Kayıt sırasında Save butonunun yanındaki katman seçimine bak.

.editorconfig ile katmanların çakıştığını unutmak. Doküman açık: .editorconfig her zaman kazanır. Rider'da değiştirdiğin bir stil ayarı "işe yaramıyorsa" önce .editorconfig'e bak.

EF'in SQL'ini olduğu gibi database aracında çalıştırmak. Gerçek çıktı: SQLite provider'ının ef_compare fonksiyonu EF dışında yok. Parametreli sorgularda da ToQueryString() parametreleri değişken tanımı olarak üretir; konsola yapıştırmadan önce SQL'i oku.

Varsayılan JVM seçenekleri dosyasını düzenlemek. Güncellemede değişiklik kaybolur, macOS'ta imza bozulur; Edit Custom VM Options kullan.

Küçük Bir Deneme

★☆☆ Kendi projende bir EF Core sorgusunun ToQueryString() çıktısını al ve database aracında çalıştır. Provider'a özgü bir fonksiyon ya da parametre tanımı çıkıyor mu?

★★☆ Kullandığın bir NuGet paketinin bir method'una Go to Declaration ile git. Kaynak Source Link'ten mi geldi, decompiler'dan mı? Paketin PDB'sinde Source Link bilgisi olup olmadığını nasıl anlarsın?

★★★ Repo'daki tekrar eden bir script'i (veri tohumlama, rapor) .NET 10 file-based app'e çevir, #:package ile bir NuGet paketi kullan ve CI'da (Continuous Integration) dotnet run tool.cs ile çalıştır. Büyüdüğünde dotnet project convert ile projeye dönüştür.

Rider'ı tanıdık. Bir sonraki yazıda üç IDE'nin extension dünyasına geçiyoruz: gerçekten işe yarayan extension'lar, Settings Sync, repo'daki önerilen extension listesi ve extension'ların senin yetkinle çalıştığı gerçeğinin güvenlik sonuçları.