Breakpoints not triggered

I am still experiencing this problem, just updated Rider to v 2019.1.1 and my project is on the same drive as the Rider binaries. Any ideas?

I run my .net 4.6.1 application in debug mode, but on every breakpoint I get: "not found associated module for breakpoint"

-Magnús

Hi there!

Thank you for your feedback.

We are truly happy to hear that you enjoy using Rider.

Frank, could you please reproduce the issue and collect Rider logs after that (Help -> Compress log and show in Explorer)?

Thanks in advance!

Dans, thank you for the such a specific case. I've created an issue in our tracking system. Please, feel free to vote for it.

Sofia

Breakpoints are now working.

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

Hi again. I do not know whether this is an intended behaviour, but now the breakpoints are triggered. Here's what it looks like:

1. I put the breakpoint. The unity is in edit mode. The breakpoint is red.

2. I start play mode. The breakpoint is greyed out with an error.

3. When a class where the breakpoints are set is touched by the execution within Unity, the breakpoints become red and are triggered.

So, it works but in a weird manner. Or is this intended?

Hi Frank,

I've just hit this issue as well, but I managed to overcome it by isolating the issue.. (At least for my case).

In my case the root cause is by having the rider folder and the solution folder on two different drives.

I am running on Linux, and in my case this means that the ~/.Rider2018.1 folder and the source code were on different drives.

When I move the source code to the same drive as Rider breakpoints started working again.

Thanks for the headsup Dans.

I reinstalled my Rider to the same drive as the solution but this sadly did not helped me :-(

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 automaticly 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...

Hi 

I am having the same trouble but it is intermittent. I've a fairly simple solution with a domain project and a web project using IIS express. I do have my project on a different hard drive than rider is installed on (64 bit rider on win 10 box). I'm still not sure what the cause is but the regular things one might try do not seem to help ...

1. Deleting bin/debug folders

2. File --> Invalidate Caches 

3. Rider restart

4. Windows restart

5. Attaching to iisexpress after it has started

At a bit of a loss as to what I might next try. Any suggestions would be helpful. 

I've updated to that build and the problem has been fixed for me. Thank you Sofia (and Jetbrains). 

I was getting this issue with skipping breakpoints in my Unity project with Untiy 2018.3.0f2 and Rider 2018.2. Rider and the project were installed on different hard drives.

Updated to Rider 2018.3 today, tried it on different hard drives, just like in the previous setup. The issue was not fixed, but I started getting grayed out breakpoints when I attach the debugger and warnings of type:

Tried re-installing Rider on the same hard drive where the project is. Still getting the same warnings and breakpoints not triggering. Deleting the csproj/sln files and obj, Temp, Library\ScriptAssemblies folders did not help. Installed Unity Hub. Not sure if I understand what is meant by "starting project by full path", but just opening the project from Unity Hub did not change anything. 

Would appreciate any help with this. 

Hello,
I've just found I have this problem, and thus this thread here. Using 2018.3.4 on Ubuntu 19.04 withing VirtualBox 6.0.6.
Just using a very basic .Net 4.7.2 HelloWorld

However, the problem appears to be fixed in 2019.1. EAP7, 6733.764, which I've just downloaded via the ToolBox.

Phew!

PS @Areftd. Hope this works for you. Compared to MonoDevelop 7,8,2 IMHO Rider is excellent.

Hello!

Denis Daniltsev Design, Racinedavid1987, this is an expected breakpoints' behavior. The thing is that mono loads classes in a lazy way. That is why Rider cannot resolve breakpoints until the corresponding class is loaded by Unity runtime.

Areftd, the Early Access Program (EAP) provides free access to pre-release builds of our products: you can try our new features out early in return for your valuable feedback. This build is now unavailable because Rider2019.1 has been released.

James, could you please describe the repro steps?

Hello, I started facing same problem after updating to  2019.1.1. My team mates faced it previously on several versions before 2019.1.1 (I just have not updated previously knowing about issue). We are using Rider on Mac to developer Xamarin applications. There are some info about my config:



Not sure is it connected somehow but in time of connecting debugger I see those events in event log:
Finally all breakpoints in shared .netstandard2.0 project looks like that(all breakpoints in Xamarin IOS project are working fine):
In previous versions of Rider I saw such notifications just after attaching debugger but closer to breakpoint(I think after appropriate class is touched) they become available, but right now they just not working. So it's actually blocker issue. I can't develop without debugger ;-D
If I can provide any additional info please ask. Thank you!

Experiencing same issue in 2019.1.1. Looks like it happens when you switch branches that have significant differences in the code. Cleaning Rider cache, solution, .idea folder, manually cleaning bin and other directories doesn't help.

We are using symlinks in Unity and this was the cause of breakpoint not being triggered. Problem solved for us.

Another thing that would probably trigger this is running 2 web apps from the same solution (i.e. web app dependent on service "api", both running at the same time). One app breakpoints work fine, another app doesn't trigger any.

I am having the same issue with breakpoints showing this tooltip:

I am running JetBrain Rider 2019.1.2 on MacOS Mojave 10.14.5.

I tried generating a lot as Sofia Byzova mentioned above.  When I went to Help->Show Log in Finder things got really odd.  It took me to /Users/dale/Library/Logs/Rider2019.1/idea.log.  But the contents of the log is a copy of the projects .gitignore file. 

I have tried deleting the various obj, bin, cache, .proj* files and anything else I could find.  It still does not work.

Cleaning and rebuilding solution worked for me and got the breakpoints to hit again. Try that.

Hello everyone,

I just wanted to let everyone know that, if like me, you were looking for a way to provide smaller and more precise publish folders you may have entered the following lines in your .csproj PropertyGroup:

<DebugType>None</DebugType>
<DebugSymbols>false</DebugSymbols>

This leaves the PDBs out of your publish, but also makes it impossible to debug your application. It seems obvious now, but I had insufficient knowledge to know more than just copy pasting this into my .csproj. I hope it can help someone else.

And how do I submit these logs to you ?
That zip is 100MB in size.

You can upload logs to our FTP, for example 

https://rider-support.jetbrains.com/hc/en-us/articles/208199755-Uploading-Large-Files-for-JetBrains-Support-Team

Frank, thanks for your reply. 

Could you please confirm that you first ran an application, opened the web page (or called a service) and only then attached a debugger?

I'm asking because the module isn't loaded before you call the application (follow a link, for example, or call a service), and this is the reason why breakpoints are not resolved before you do this.

So, to use a debugger you just need to start debugging session and open a web page (or call a service ) of the application. After that, breakpoints will be resolved.

Perhaps, the message "Not found associated module for breakpoint" is not the best in the case above.  I created an issue, and we will try to improve usability.

Very weird.

I would appreciate if you collect and send us DebuggerWorker logs (Help -> Show logs in Explorer / Finder). 

Have the same problem. 

But I have a bit tricky configuration (which works perfectly in Visual Studio though).

I have a separate project, which builds before main, then target DLL copies into Plugins directory for main project and main project loads all DLLs from Plugins directory into AppDomain.

In log I can see:

```

14:09:10.683 |T| SEND | Debugger worker MTA main thread:3 | signal `DebuggerWorkerToFrontend.DebuggerWorkerModel.activeSession.$.debuggerOutput` (5773224205282569435):: value = OutputMessage (
output = "Pdb file for assembly <assembly name> was not found or failed to read
"
type = Info
subject = Default
)

```

I have the same problem, also affecting Rider 2018.2.3. My prpject used to be on the same drive as the Rider binaries. When I move the project to a different drive, breakpoints do not work anymore with message 'not found associated module for breakpoint Main.cs 21,4' which is the location of the breakpoint. Just moving the solution back to the original physical drive solves the problem.

In my case the Rider binaries are on the same drive as the project but that is not the same drive as ~/.Rider2018.2. Moving the project to the same drive as where ~/.Rider2018.2 is, then it does not work.

I have not used Visual Studio at all in this project. It is al 'Linux only' built version. I am on Linux Mint (Ubuntu 18.04 based).

Having the same issue, however I moved the project to the same drive as .rider folder and the rider binaries themselves, so everything located on the same drive, the rider is the version 2018.3 EAP 3 (183.3647.257) version.

I'm using ubuntu 18.04

In my case the project is being run through :

/usr/bin/mono --debug --debugger-agent=transport=dt_socket,server=y,suspend=y,address=127.0.0.1:55555,setpgid=y /usr/lib/mono/4.5/xsp4.exe --address=127.0.0.1 --port=5000

I've uploaded the logs to your servers at https://uploads.services.jetbrains.com/

the file name is: 

logs-20181021-185657.zip

Can't debug, which is very very frustrating, what can I do to help you fix this problem?

 Thank you,

Update: After cleaning the solution and reopening it not through symlink, but directly I was able to debug it.

So my issue is exactly the same as the others, where the solution must be located on the same disk as the rider binaries in order for the debug to work, I have a strong suspicion that the mono process (/usr/bin/mono) also must be located on the same disk.

Thank you,

Hi

At the moment debugger does not work with symlinks. Here is a corresponding issue.

Hello!

The fix is available in Rider 2018.3 EAP.

Please, try it and feel free to let me know if the problem persists.

Had the same issue and fixed it. In my case problem appeared when I start project from mounted drive (via subst). Solved by starting project by full path (via Unity Hub) and cleaning csproj/sln files and obj, Temp, Library\ScriptAssemblies folders

Windows 10, Unity 2018.2.13f1, Rider 2018.3.1