Yıllarca Windows'ta .NET yazdım, sonra Mac'e geçtim — Rider'da ilk çarptığım duvar klavye oldu

Visual Studio keymap'ini seçmek yetmiyor: Rider'ın Mac sürümü Windows'takinin 41 kısayolunu hiç tanımlamıyor. Keymap dosyalarını açtım, ayarlarımı tek tek döktüm.

Bu yazının İngilizcesi: English version.

Visual Studio'dan Rider'a geçen her .NET geliştiricisinin ilk yaptığı şey aynı: ayarlarda keymap listesini açıp "Visual Studio" seçeneğini tıklamak. Kas hafızası duruyor, IDE değişiyor, hayat devam ediyor. Mac'te ise listede "Visual Studio OSX" yazıyor ve onu seçiyorsunuz.

Ben de öyle yaptım ve iki yıl boyunca bazı kısayolların neden "yanlış" davrandığını anlamadım. Geçen gün oturup Rider'ın keymap dosyalarını açtım. Meğer "Visual Studio OSX", Windows'taki Visual Studio keymap'inin Mac'e uyarlanmış hâli değil — eksik hâli.

Aşağıdakiler ölçüm, tahmin değil. Rider 2026.2 (build RD-262.8665.400), .NET SDK 10.0.302, Apple Silicon Mac.

Önce iyi haber: kısayolların çoğu birebir çevriliyor

Boşlukları birazdan tek tek sayacağım, ama işin büyük kısmı gayet basit — Windows'taki Ctrl yerine ⌘ basıyorsunuz. Günlük kullandıklarım:

Son satır tuzak: son dosyalar ⌘, değil ⌃,. Çünkü ⌘, macOS'ta evrensel olarak "ayarlar" demek ve JetBrains ona dokunmamış. Mantıklı, ama parmaklar bunu bilmiyor.

Aşağıdaki beşi günlük hayatta en çok kullandıklarım. Tuşlara hangi sırayla basıldığını göstereyim:

Evet, Ctrl+K, D duruyor — ⌘K, D olarak

Visual Studio'da dosyayı biçimlendirmek için parmağıma kazınmış olan Ctrl+K, D beni Rider'a geçerken en çok endişelendiren şeydi. Keymap dosyasına baktım: duruyor, hem de beş ayrı kombinasyonla. ReformatCode eylemi Mac'te şunlara bağlı:

Bir de VS'te pek karşılığı olmayan, benim biçimlendirmeden daha çok kullandığım bir şey var: kod temizliği. ⌘E sonra C temizlik profili seçtiriyor, ⌘E sonra F seçili profili sorusuz uyguluyor — using'leri düzenlemek, this. eklerini normalleştirmek, gereksiz parantezleri atmak tek tuşta oluyor. Bir dosyayı devraldığımda ilk yaptığım şey bu.

Çift Shift: keymap'i değiştirince kaybetmediğiniz tek şey

Rider'da bir şeyi ararken ⌘T'ye basmam gerektiğini biliyorum ama pratikte hep Shift'e arka arkaya iki kez basıyorum. Bu, sınıf da olsa dosya da olsa ayar penceresindeki bir kutucuk da olsa aynı kutuyu açıyor.

İlginç olan şu: on iki keymap dosyasının hiçbirinde shift shift diye bir bağ yok. Kontrol ettim, sıfır eşleşme. Çünkü bu bir kısayol değil, platformun kendi el hareketi — hangi keymap'i seçerseniz seçin çalışıyor. Yani Visual Studio keymap'ine geçtiğinizde kaybettiğiniz 41 şeyin arasında bu yok.

⌥F1: "bu dosya çözümün neresinde?"

Visual Studio'da kodun içindeyken açık dosyayı Solution Explorer'da bulmak için "Sync with Active Document" düğmesine basardım. Rider'ın karşılığı ⌥F1 ve daha fazlasını yapıyor: bir menü açılıyor, dosyayı nerede göstermek istediğinizi soruyor — çözüm ağacında, Finder'da, terminalde, dosya yolunu panoya kopyalayarak.

Bu da birazdan anlatacağım 41 boşluktan biri: SelectIn eylemi ne Windows ne Mac Visual Studio keymap'inde tanımlı; tuş IntelliJ'in Mac keymap'inden geliyor. Yani VS belgelerine bakarak bunu asla bulamazsınız. Çözüm ağacını komple açmak için ise ⌘1 (VS'teki Alt+1) yeterli.

Visual Studio'daki dört alışkanlığın Rider karşılığı

Kısayollar bir yana, asıl "bu nerede?" dediğim şeyler günlük işlerdi. Dördü sık sorulan cinsten:

Çözüme yeni proje eklemek

VS'te çözüme sağ tıklayıp Add → New Project. Rider'da aynı yol var, ama kısayolu bilmek daha hızlı: çözüm ağacında düğümü seçip ⌘N. Seçtiğiniz düğüme göre menü değişiyor — çözümün üstündeyken proje, projenin üstündeyken sınıf/arayüz/kayıt sunuyor.

Burada bir tuzak var: ⌘N ile ⌃⌘N aynı şey değil. Kod editörünün içindeyken ⌃⌘N "üye üret" (constructor, Equals, arayüz uygulaması) demek. Yani aynı harf, imlecin nerede olduğuna göre iki farklı işi yapıyor. Alışması bir gün sürüyor.

EF Core migration eklemek

Visual Studio'daki Package Manager Console alışkanlığının (Add-Migration Filan -StartupProject ...) Rider'da doğrudan karşılığı yok — PMC diye bir pencere yok. İki yol var.

Birincisi terminal, ki her zaman çalışır:

dotnet ef migrations add IlkSurum --project src/Filan.Infrastructure --startup-project src/Filan.Api
dotnet ef database update --project src/Filan.Infrastructure --startup-project src/Filan.Api

İkincisi, benim kullandığım: Rider EF Core arayüzünü kutudan çıkmış hâlde getiriyor. Ayrı ayrı kurmaya gerek yok, kurulumun bundled_plugins.txt dosyasında görünüyor:

grep efcore ~/Library/Application\ Support/JetBrains/Rider2026.2/bundled_plugins.txt
# me.seclerp.rider.plugins.efcore|null

Projeye sağ tıklayıp Tools → Entity Framework Core → Add Migration diyorsunuz, açılan pencerede migration adını yazıyorsunuz. Asıl kazanç şurada: migration projesi ile startup projesi eşleşmesini bir kere seçiyorsunuz, sonra hatırlıyor. PMC'de her komutta -StartupProject yazmaktan kurtuluyorsunuz. Kendi ayar dosyamda bu eşleşmenin kayıtlı durduğunu görebiliyorum:

cat ~/Library/Application\ Support/JetBrains/Rider2026.2/options/efCoreCommonOptions.xml
# <option name="migrationsToStartupProjects"> ... GUID → GUID

Pencere aşağı yukarı şöyle dolduruluyor:

Katmanlı bir çözümde DbContext'in Infrastructure'da, Program.cs'in Api'de durduğu klasik kurulumda bu ayrımı her seferinde yeniden anlatmak zorunda kalmamak ciddi rahatlık.

Commit ekranında "stage" alanını geri getirmek

Rider bunu varsayılan olarak kapalı getiriyor ve Visual Studio'nun Git Changes penceresinden gelen biri için bu ilk gün kafa karıştırıcı: değişiklikler tek listede duruyor, stage edecek bir yer yok. Açması tek kutucuk:

Settings → Version Control → Git → Enable staging area

Açtıktan sonra commit penceresi VS'teki gibi ikiye bölünüyor: stage'lenmiş ve stage'lenmemiş değişiklikler ayrı. Ayar dosyamda hâlâ açık duruyor:

grep STAGING_AREA ~/Library/Application\ Support/JetBrains/Rider2026.2/options/git.xml
# <option name="STAGING_AREA_ENABLED" value="true" />

Commit penceresini açan kısayol da ayrıca bir tutarsızlık örneği: Windows keymap'inde Ctrl+Alt+K, Mac keymap'inde ⌘⌥⇧K. Fazladan bir Shift var ve nedenini bulamadım.

Commit listesini VS'teki gibi klasör ağacı yapmak

Bu benim en çok özlediğim şeydi. Rider commit penceresinde değişen dosyaları düz bir liste olarak gösteriyor; Visual Studio ise klasör ağacı veriyor ve on dört projeli bir çözümde bu fark büyük.

Çözüm gizli değil ama görünür de değil: commit penceresindeki dişli (ayarlar) simgesi → Group By → Directory. Eylemin kimliği ChangesView.GroupBy.Directory; aynı menüde birden fazla depo ile çalışanlar için Repository seçeneği de var. Bir kere işaretliyorsunuz, kalıyor.

Peki o 41 boşluk ne? Keymap dosyalarını açtım

Buraya kadarki her şey çalışıyor. Şimdi çalışmayanlara gelelim — çünkü asıl vakit kaybettiren yer orası.

Rider'ın Visual Studio keymap'i uygulamanın içinde bir eklenti olarak duruyor:

unzip -o /Applications/Rider.app/Contents/plugins/keymap-visualStudio/lib/keymap-visualStudio.jar -d /tmp/vskeymap
ls /tmp/vskeymap/keymaps/
# Visual Studio OSX.xml
# Visual Studio.xml

İki dosyayı ayrıştırıp içerdikleri action kimliklerini karşılaştırdım:

41 eylem Windows sürümünde bağlı, Mac sürümünde hiç yok. Karşılığında Mac sürümünün fazladan tanımladığı 10 eylem var, ama onların çoğu zaten Mac'e özel şeyler (⌘F4 ile sekme kapatma gibi).

Burada kritik nokta şu: bir eylem keymap dosyasında yoksa kısayolsuz kalmıyor. Üst keymap'ten, yani IntelliJ'in Mac kısayollarından miras alıyor. Yani basacağınız tuş ne Visual Studio'nunki oluyor ne de "hiçbir şey" — üçüncü, bambaşka bir tuş oluyor. En can yakan altısı:

Ben yıllarca Ctrl+Shift+Space'in Mac karşılığının ⌘⇧Space olduğunu sandım. Değilmiş. ⌃P imiş — hem de Visual Studio ile hiç ilgisi olmayan, IntelliJ'in varsayılan tuşu.

F5 sizin bildiğiniz F5 değil

Bunu keşfetmek keymap'i açmamı gerektirmedi, ilk gün canımı yaktı ama nedenini şimdi belgeleyebiliyorum:

Yani Visual Studio'daki F5, Rider'da ikiye bölünmüş durumda. Çalışan bir oturum yokken F5'e basmak hiçbir şey yapmıyor ve insan bir süre IDE'nin donduğunu sanıyor.

Sekiz kısayol, Mac klavyesinde varsayılan olarak erişilemez

"Visual Studio OSX" keymap'i toplam 277 tuş kombinasyonu tanımlıyor. Bunların 40'ı bir F-tuşu içeriyor, 8'i ise çıplak F-tuşu — hiçbir değiştirici tuş olmadan. Hangileri olduğuna bakın:

Yani hata ayıklamanın tamamı çıplak F-tuşlarında. MacBook klavyesinde bu tuşlar varsayılan olarak parlaklık ve ses tuşları; Rider'a ulaşmaları için Fn'e basmanız gerekiyor. Kendi makinemde kontrol ettim:

defaults read -g com.apple.keyboard.fnState
# The domain/default pair ... does not exist  → yani kapalı

Ayar hiç yazılmamış, dolayısıyla varsayılan geçerli: kapalı. Bu, Visual Studio keymap'ini seçen her Mac kullanıcısının aslında Fn+F9, Fn+F10, Fn+F11 diye hata ayıkladığı anlamına geliyor. Düzeltmesi tek yer: System Settings → Keyboard → "Use F1, F2, etc. keys as standard function keys". Bir kutucuk, sekiz kısayol.

macOS'un çaldığı iki tuş

Sekme geçişi Mac keymap'inde iki kısayola bağlı: ⌘⇧[ / ⌘⇧] ve ⌃← / ⌃→. İkincisi macOS'ta masaüstleri arasında geçiş yapıyor. Kendi ayarlarıma baktım, ikisi de açıktı:

/usr/libexec/PlistBuddy -c "Print" ~/Library/Preferences/com.apple.symbolichotkeys.plist | grep -A4 "79 = Dict"
# enabled = true, keycode 123 (sol ok), Control

Yani ⌃←'e bastığımda Rider'da sekme değişmiyor, masaüstüm kayıyor. İki çıkış yolu var: ya ⌘⇧[ alışkanlığı edinirsiniz (ben bunu seçtim), ya da System Settings → Keyboard → Keyboard Shortcuts → Mission Control altından "Move left/right a space" kısayollarını kapatırsınız. Ben masaüstlerini kullandığım için Rider tarafından feragat ettim.

Değiştirdiğim ayarlar ve nedenleri

Keymap dışında Rider'ı kutudan çıktığı gibi kullanmıyorum. Ayar dosyalarımı (~/Library/Application Support/JetBrains/Rider2026.2/options/) döküp ne değiştirdiğimi çıkardım. Hepsi tek tek bir sinir bozukluğunun cevabı:

Bir de kod kapsama ölçerken hep aynı gürültüyü elediğim için dotCover filtresini bir kez global olarak yazdım: System.*||Microsoft.*||JetBrains.*. Her çözümde tekrar tanımlamaya gerek yok.

Neyi değiştirmedim

Özel bir keymap oluşturmadım. Denedim, iki hafta sonra sildim. Sebebi şu: kendi kısayollarınızı tanımladığınız anda her JetBrains belgesi, her Stack Overflow cevabı ve her ekip arkadaşınızın ekranı sizin için yanlış hâle geliyor. Hazır keymap'in 41 boşluğunu öğrenmek, 41 boşluğu doldurmaktan uzun vadede daha ucuz çıktı.

Şunu da dürüstçe söyleyeyim: keymap'i açıp saymadan önce bu boşlukların varlığını bilmiyordum, sadece "bazı şeyler tuhaf" diye hissediyordum. Aracınızın yapılandırma dosyalarını bir kez okumak, iki yıllık belirsiz bir rahatsızlığı yarım saatte bitiriyor. Bu bence Rider'a da özel değil.

← Tüm yazılar