Rider 2019.1 is a wreck right now in Unity3D

The debugger stopped working. It blabbers about something related to the module not being found. Obviously this was working fine in 2018.1.4, because I just tested it.

The solution just hangs on loading structure sometimes.

Autocomplete sometimes gets horribly slow.

It's just a bunch of regressions.

6 comments
Comment actions Permalink

Hi all,
Unfortunately can confirm this behavior.
With newest Rider debugging Unity3d works for me but is slower to start.
The biggest issue is "evaluate expression" which takes 5-20 seconds to trigger that window.
In general, during debugging, also "hover over variable" doesn't do anything, doesn't show any popup with actions/values, all is just terribly slow.
There are other performance issues as well but most of them are recorded(like slow autocomplete etc.)

With older Rider, 2018.3(RD-183.6246.12) everything just works.

The error when starting debugger: "Debug symbols for assembly nunit.framework could not be loaded correctly. Mono runtime doesn't support full pdb"

Rider build RD-191.6733.985

Linux Mint 16.04

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Unity 2018.2.21

Will check soon if this issue is already reported and if not will do it.

0
Comment actions Permalink

I'm getting this with the new version:

 

Debug symbols for assembly nunit.framework could not be loaded correctly. Mono runtime doesn't support full pdb

2
Comment actions Permalink

Hello,

The warning "Debug symbols for assembly nunit.framework could not be loaded correctly. Mono runtime doesn't support full pdb." itself should not affect the development process. The message means that there are no valid *.pdb files near nunit.framework assembly on your computer for the scripting runtime version configured in Unity settings. Therefore, you won't be able to step into nunit.framework code. Could you please check if there is a pdb file near nunit.framework.dll? You can get the .dll path from the reference properties. 

0
Comment actions Permalink

Unfortunately I have also issues with the debugger. I recently updated from Rider 2018.something I think it was 2018.3

and since then I am having severe issues debugging with Unity 2018.3.10f1. Many times Unity freezes and theres only two ways to continue: Killing/Restarting Unity or disconnecting the debugger. Both are not really feasible options if i need to debug something. For me mostly it works for the first  breakpoints, so a typical flow looks like this:

1. Set a few breakpoints
2. Attach debugger
3. Run unity either directly from rider or from unity itself
4. first breakpoint(s) gets hit, i can step and so on everything works fine
5. I return to unity to trigger an action that triggers another breakpoint
Current Result: Unity reacts fine until i trigger the next breakpoint. That breakpoint does not actually show up in rider so rider looks like unity is still running but unity is not responding and i only see the Mac loading wheel. - Again: if i disconnect the debugger, Unity returns to normal

 

0
Comment actions Permalink

Hello Iris,

I am very sorry to hear you have faced with such difficulties, could you please collect the logs for investigation:

  1. Enable Debug trace scenario (Help -> Trace Scenarios)
  2. Start debugging session and reproduce the issue
  3. Collect logs via Help -> Compress log...
  4. Don't forget to disable the trace scenario. Otherwise, Rider will write lots of information in the log.

And upload the resulting log here or create a new issue on YT: https://youtrack.jetbrains.com/newIssue and attach logs to it? Thank you in advance!

1

Please sign in to leave a comment.