I’ve spent the past few years on a shiny microservices stack project — Docker‑everything, cloud‑native, .NET versions on the cutting edge. macOS + Rider = bliss.
Then came the pivot: a legacy enterprise web app written in ASP.NET WebForms, running on IIS. Normally that means surrendering your Mac to Windows — complete with clunky keybinds, battery-draining inefficiencies, and every Windows quirk you’ve repressed since 2007 (oh and Microsoft copilot… on your keyboard). I begrudgingly switched… until JetBrains dropped a lifeline: Remote Development.
The Setup: A Windows VM Without the Suffering
I’d been tracking this feature before its early beta builds on YouTrack, refreshing the page like a kid waiting for Christmas. When it finally went public, I pounced.
Step 1: The Bare-Minimum Windows VM
First, I fired up a Windows 11 VM in Parallels (VirtualBox works too), enabled IIS and ASP.NET via Windows Features, and installed JetBrains Toolbox. Rider came next.
“This is where most guides stop,” I thought. Normally, you’d just run Rider or Visual Studio inside the VM, squinting at a laggy Windows UI. But why tolerate that when we can go full remote?
Step 2: Network stuff – SSH, Ports, and Avoiding Conflicts
SSH Keys First:
On Mac: ssh-keygen -t ed25519 (skip if you’ve done this before).
On the VM: Install OpenSSH Server via Windows Features, then paste your public key into C:\Users\vmuser\.ssh\authorized_keys.
Port forwarding for SSH.
- Go to Parallels Desktop > Devices > Network > Configure…
- Follow Advanced > Open Network Preferences > Port forwarding rules
- Set forward for Source=2222 → Destination=22
My Mac’s own SSH runs on port 22. By forwarding Mac port 2222 → VM port 22 in Parallels, I dodged conflicts. No sudo, no fuss.
Step 3: JetBrains’ Remote Magic
Before you continue further, you need to turn off the Toolbox app on your Windows VM or you will not be able to connect to it.
In the Toolbox app on my Mac:
- Click the dropdown which currently has Local selected → SSH.
- Type
vmuser@localhost:2222(replace with your username)
- Launch Rider.
The Big Reveal:
Rider’s UI runs natively on my Mac, but its backend — compilation, debugger, IIS environment — lives on the VM. It’s like outsourcing Windows’ dirty work.
Running the System
First run
I tried just pressing the big green play button in the Rider’s toolbar, but after the app launched I remembered I cannot really access it due to it running in a separate virtual network device.
Port Forwarding
My app runs on IIS port 80, but macOS requires sudo to bind low ports. My fix: Forward Mac port 8000 → VM port 80 in Parallels.
With some tinkering you could probably get the ports 80/443 working as well, but for now this is a fine solution for me.
Debugging
First debug attempt: Nothing. Maybe it’s just when using IIS for running the app, maybe it’s due to some bug in the remote development. IIS spawns the process after Rider starts debugging. My fix is:
- Launch the app.
- In Rider: Attach to Process →
w3wp.exe(or something similar). - Now all your breakpoints and console output will be available
Why Bother? (And Reality Checks)
For the stubborn: This setup feels like developing locally on a Mac. No VM UI lag, no Windows keybind amnesia.
For the pragmatic: It’s fragile. The client occasionally loses connection (especially after sleep), port forwarding can glitch, and the VM easily needs 8GB+ RAM. I’ve got 32GB on my MacBook, and even that can sometimes not be enough for all the development tools I use.
Final Thoughts
This isn’t about efficiency—it’s about preserving your workflow while dealing with legacy world of .NET. JetBrains hasn’t fixed .NET Framework, but they’ve let me debug them on my terms: far away from a power socket, with macOS shortcuts, and a cold drink in hand.
Next time, about those microservices…