Breakpoints not being hit in JetBrains Rider?

Question

I am trying to set a breakpoint in JetBrains Rider, but the debugger isn't breaking.

I know for sure the application should reach the code I'm trying to break on, as changing string literals appears in the program.

I have completely reinstalled all my JetBrains programs (wiping settings). I've also tried every answer in this thread: break point is not hitting while debugging, with no luck.

This bug doesn't occur in Visual Studio, but does occur with any project in Rider.

It also doesn't happen on my other copy of Rider that I use on my other PC.

I appreciate any help, thanks!

Immunology

Answer 1

I've found what was causing it.

As of Rider 2018.1.3, the solution you're running must be on the same disk as the copy of Rider you're using.

This issue is referenced on JetBrains support here.

You can temporarily solve this by either moving your solution to the same drive, or by reinstalling Rider.

Immunology

This was my issue too but debugging worked in VS2019 - In Rider, when hovering over the disabled breakpoint, you will see a message like module not found in D:\Folder\Code\Script.cs. Move the project to the same drive as rider, clean the solution, restart windows, run from Rider successfully hit breakpoint. Also make sure your Unity project build settings have "Development mode" and "Script debugging" enabled. – Supposititious

Is this still the case in 2023.1.1 version? – Cursorial

Doesn't look like it, my personal copy of Rider is on a different hard drive to most of my solutions, and I can debug ok (running Rider 2023.1) – Immunology

Answer 2

One more caveat: I started using Rider again after an absence, I was pressing the "play" (triangle) button rather than the button with a picture of a bug.

(D'oh!)

Steelman

Also a note for those who switched from VS like me: The F5 key does not start debugging, it just runs the code; even when using the VS keymaps. – Pederson

I was doing the same thing. Thanks – Physiologist

Still saving lives in 2023 😆 – Simplistic

Rider says it imported key maps from VS. But it still preserves some of it "iconic" key maps. – Choker

Answer 3

This can happen if Rider attaches the debugger to a different process than the process that IIS is using.

• Open Run on the Rider menu and click on "Attach to process" or ctrl+alt+F5
• Type w3wp, this will find all the processes IIS is running on. Now if you see multiple processes you can hover on them to determine which AppPool is related to that process.
• Click on the process to attach the debugger to it.
• The breakpoint should be hit now.

And, make sure you are using the correct URL that Rider provides you when you run your project (http://localhost:XXXX), because the URL that Rider uses might be different from the Host Name you set for your IIS site.

Mayamayakovski

Answer 4

What I did before was :

1. Open the solution
2. Set some breakpoints
3. Click the 'bug' button in Rider (next to the play button)
4. Chrome would open up automatically with an URL pointing to my services
5. The service would work as expected, but breakpoints would not work
6. Stop the service
7. Modify some code
8. Start the service
9. Refresh the Chrome Windows from step 4
10. I would see the modifications in Chrome. But no breakpoints would get hit.

Now the only thing I changed is that in after step 2 I now do a

Run --> Attach to a local process... --> w3wp

After this, I just do the same steps as before, but now the breakpoints do get hit...

Refrence

Gimble

Answer 5

If you're using .NET core and IIS, make sure the Application pool has 'No Managed Code' under '.NET CLR Version' in the Basic Settings:

Trask

Answer 6

For anybody who has the same problem in Xamarin Android project. For me the breakpoints in the android project where working, like in the main activity but not in the shared project.

How i fixed it: Go to your android.csproj file and edit it. Search your build target and check for <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk> If this is true, breakpoints in additional modules are not working. Set it to false, or even better, remove this line completely.

Lungfish

Answer 7

In relation to Jessica's answer above, it appears that opening a solution in Rider using the System absolute path (i.e. /System/Volumes/Data/Users/...) appears to act as though it's on a separate drive.

After driving myself crazy for about four hours, I created a new solution and changed the solution directory from the system path to /Users/... then copied my project to this new solution which fixed the breakpoints, and opening the project from the Rider welcome screen now shows the solution directory as a relative path (~/Users/...)

Extenuatory

Answer 8

Another solution for you (or other people who come across this):

When you have "COMPlus_EnableDiagnostics": "0" in your configuration or launchSettings you won't be able to hit breakpoints either.

Moonfaced

Ummm where the heck is this setting to be found? – Rollick

It can be set via an Enviroment Variable. appsettings.json, launchsettings... – Moonfaced

Answer 9

Cleaning and rebuilding the solution, and then removing and readding the breakpoint worked for me!

Allargando

Answer 10

None of these solutions worked. Solutions of clearing caches through the Rider interface and stuff like that, none of them worked. None of them.

The problem: a previously working referenced project of custom code (not some external library or nuget package) broke the breakpoints. Breakpoints outside the package worked, but not in the referenced project. I was getting that "stop sign" symbol in which it couldn't resolve a method.

The only thing that worked was to completely erase all instances, and previous instances, of Rider from Application Support and Caches on my mac. After following the instructions to completely erase Rider on their website, and then reinstalled it, I was able to get the breakpoints working again. Sorry, but for some of you this may be the only thing you can do.

Tiger

Answer 11

I had this problem too and the cause was a spurious <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild> in the csproj. Removing this setting restored debugging capabilities.

Caril

Answer 12

In my case the breakpoint not being hit when debugging a project with IIS Express.

The issue has been solved after running Rider as administrator

Thanks to @David smith's answer here: Can JetBrains Rider work properly with IISExpress?

Sjambok

Answer 13

I encountered this issue while running an Azure Functions project in Rider. If the debugger isn't attaching properly, make sure to set the FUNCTIONS_WORKER_RUNTIME environment variable. Adding this variable fixed the issue for me.

Suzannasuzanne