I wrote .NET on Windows for years, then moved to a Mac — the first wall I hit in Rider was the keyboard

Picking the Visual Studio keymap isn't enough: Rider's macOS version leaves 41 of the Windows shortcuts undefined. I opened the keymap files and dumped every setting I'd changed.

Bu yazının Türkçesi: Türkçe sürüm.

Every .NET developer moving from Visual Studio to Rider does the same thing first: open settings, find the keymap list, click "Visual Studio". Muscle memory survives, the IDE changes, life goes on. On a Mac the list says "Visual Studio OSX" and you pick that one.

I did exactly that, and for two years I never understood why certain shortcuts behaved "wrong". The other day I sat down and opened Rider's keymap files. It turns out "Visual Studio OSX" isn't the Windows Visual Studio keymap adapted to macOS — it's the Windows keymap with holes in it.

Everything below is measured, not guessed. Rider 2026.2 (build RD-262.8665.400), .NET SDK 10.0.302, Apple Silicon Mac.

First the good news: most shortcuts translate one-to-one

I'll count the holes one by one in a minute, but the bulk of it is simple — press ⌘ where Windows says Ctrl. The ones I use daily:

The last row is the trap: recent files is ⌃,, not ⌘,. Because ⌘, universally means "settings" on macOS and JetBrains sensibly left it alone. Sensible, but your fingers don't know that.

These five are the ones I reach for daily. Here's the order the keys go down in:

Yes, Ctrl+K, D survived — as ⌘K, D

Ctrl+K, D for formatting a document is burned into my fingers, and it was the thing I worried about most when switching. I checked the keymap file: it's there, bound to five different combinations. The ReformatCode action on macOS answers to:

There's also something with no real VS equivalent that I use more than formatting: code cleanup. ⌘E then C lets you pick a cleanup profile, ⌘E then F applies the selected one without asking — organizing usings, normalizing this. prefixes, dropping redundant parentheses, all in one keystroke. It's the first thing I run on a file I've inherited.

Double Shift: the one thing you don't lose by switching keymaps

I know I'm supposed to press ⌘T to find something in Rider, but in practice I always hit Shift twice in a row. It opens the same box whether I'm after a class, a file, or a checkbox buried in the settings dialog.

Here's the interesting part: none of the twelve keymap files contains a shift shift binding. I checked — zero matches. It isn't a shortcut at all, it's a platform gesture, so it works no matter which keymap you pick. Which means it isn't among the 41 things you lose when you switch to the Visual Studio keymap.

⌥F1: "where does this file live in the solution?"

In Visual Studio I'd hit the "Sync with Active Document" button to locate the open file in Solution Explorer. Rider's equivalent is ⌥F1, and it does more: a menu appears asking where you want to reveal the file — the solution tree, Finder, the terminal, or just copying its path.

This is one of the 41 gaps I'm about to walk through: the SelectIn action isn't defined in either the Windows or the macOS Visual Studio keymap, so the key comes from IntelliJ's Mac keymap. You will never find it by reading Visual Studio documentation. To open the solution tree outright, ⌘1 (VS's Alt+1) does the job.

Four Visual Studio habits and their Rider equivalents

Shortcuts aside, the things that really made me ask "where is this?" were everyday jobs. Four of them come up constantly:

Adding a new project to the solution

In VS you right-click the solution and pick Add → New Project. Rider has the same path, but the shortcut is faster: select the node in the solution tree and press ⌘N. The menu adapts to what's selected — a project when you're on the solution, a class/interface/record when you're on a project.

One trap: ⌘N and ⌃⌘N are not the same thing. Inside the code editor, ⌃⌘N means "generate member" (constructor, Equals, interface implementation). Same letter, two different jobs depending on where the caret is. Takes about a day to internalize.

Adding an EF Core migration

The Package Manager Console habit (Add-Migration Foo -StartupProject ...) has no direct equivalent in Rider — there is no PMC window. There are two ways round it.

The first is the terminal, which always works:

dotnet ef migrations add InitialCreate --project src/Foo.Infrastructure --startup-project src/Foo.Api
dotnet ef database update --project src/Foo.Infrastructure --startup-project src/Foo.Api

The second is what I actually use: Rider ships the EF Core UI out of the box. Nothing to install; it shows up in the installation's bundled_plugins.txt:

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

Right-click the project, pick Tools → Entity Framework Core → Add Migration, type the migration name. The real win is this: you choose the migrations project / startup project pairing once, and it remembers. No more typing -StartupProject on every command. I can see that pairing sitting in my own settings file:

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

The dialog fills in roughly like this:

In the classic layered setup where DbContext lives in Infrastructure and Program.cs in Api, not having to re-explain that split every single time is a genuine relief.

Getting the staging area back in the commit window

Rider ships with this off by default, and for someone coming from Visual Studio's Git Changes window that's disorienting on day one: all your changes sit in one list with nowhere to stage them. One checkbox fixes it:

Settings → Version Control → Git → Enable staging area

After that the commit window splits in two like VS: staged and unstaged changes, separately. It's still on in my settings file:

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

The shortcut that opens the commit window is its own little inconsistency, by the way: Ctrl+Alt+K in the Windows keymap, ⌘⌥⇧K on the Mac one. There's an extra Shift in there and I couldn't find out why.

Making the commit list a folder tree, like VS

This is the one I missed most. Rider shows changed files as a flat list; Visual Studio gives you a folder tree, and in a solution with fourteen projects that difference is not small.

The fix isn't hidden, but it isn't visible either: the gear (settings) icon in the commit window → Group By → Directory. The action ID is ChangesView.GroupBy.Directory; the same menu offers Repository for people working across several repos. Tick it once and it sticks.

So what are those 41 gaps? I opened the keymap files

Everything above works. Now for the parts that don't — because that's where the time actually goes.

Rider ships the Visual Studio keymap as a plugin inside the app bundle:

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

I parsed both files and compared the action IDs they define:

41 actions are bound in the Windows version and completely absent from the macOS one. The macOS keymap does add 10 of its own, but most are Mac-specific things like closing a tab with ⌘F4.

Here's the part that matters: an action missing from a keymap file does not end up unbound. It inherits from the parent keymap — IntelliJ's own macOS shortcuts. So the key you press is neither the Visual Studio one nor nothing at all; it's a third, unrelated key. The six that hurt most:

For years I assumed the Mac equivalent of Ctrl+Shift+Space was ⌘⇧Space. It isn't. It's ⌃P — a key that has nothing to do with Visual Studio at all.

F5 is not the F5 you know

I didn't need the keymap files to discover this one; it bit me on day one. But now I can document why:

Visual Studio's F5 is split in two in Rider. With no session running, pressing F5 does nothing at all, and you spend a while thinking the IDE has frozen.

Eight shortcuts you can't reach on a default Mac keyboard

The "Visual Studio OSX" keymap defines 277 key combinations in total. 40 of them involve a function key, and 8 are bare function keys with no modifier. Look at which ones:

The entire debugging workflow sits on bare function keys. On a MacBook keyboard those are brightness and volume keys by default; reaching Rider requires holding Fn. I checked my own machine:

defaults read -g com.apple.keyboard.fnState
# The domain/default pair ... does not exist  → so it's off

The setting was never written, so the default applies: off. Which means every Mac user who picks the Visual Studio keymap is actually debugging with Fn+F9, Fn+F10, Fn+F11. One place fixes it: System Settings → Keyboard → "Use F1, F2, etc. keys as standard function keys". One checkbox, eight shortcuts.

Two keys macOS steals

Tab switching is bound to two shortcuts in the Mac keymap: ⌘⇧[ / ⌘⇧] and ⌃← / ⌃→. The second pair moves between desktops in macOS. I checked my settings — both were enabled:

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

So when I press ⌃←, my tab doesn't change; my desktop slides sideways. Two ways out: build the ⌘⇧[ habit (what I did), or turn off "Move left/right a space" under System Settings → Keyboard → Keyboard Shortcuts → Mission Control. I actually use desktops, so I gave that one up on the Rider side.

The settings I changed, and why

Beyond the keymap I don't run Rider as it comes. I dumped my settings files (~/Library/Application Support/JetBrains/Rider2026.2/options/) and worked out what I'd actually changed. Every one of them is the answer to a specific irritation:

I also set the dotCover filter globally once, since I exclude the same noise in every solution: System.*||Microsoft.*||JetBrains.*. No need to redefine it per project.

What I didn't change

I never built a custom keymap. I tried, and deleted it two weeks later. The reason: the moment you define your own shortcuts, every JetBrains doc, every Stack Overflow answer and every colleague's screen becomes wrong for you. Learning the 41 holes in a stock keymap turned out cheaper long-term than filling them.

And to be honest: before I opened the keymap files and counted, I didn't know those holes existed — I just had a vague sense that "some things are weird". Reading your tool's configuration files once turns two years of low-grade discomfort into half an hour of work. I don't think that's specific to Rider.

← All posts