Rider 2017.3 and Unity

Rider 2017.3 was a bumper release and added a lot of new features, improvements and fixes. Let’s take a look at the Unity specific changes.

As a quick reminder, Rider is a cross platform C# IDE, for Windows, Mac and Linux, with built-in support for Unity. Rider happily opens, builds and tests Unity projects, with deep knowledge of the API and the way Unity uses your code, highlighting usages of Unity’s event functions and serialised fields and more.

What’s new?

First of all, we finally get a small but highly requested feature – Rider will now display external documentation for Unity symbols. Rider has displayed a summary tooltip on Unity types and event functions for a while now, but we’ve been missing the ability to view a web page with detailed help. Now, you can either click the icon from the Quick Documentation popup (Ctrl+Shift+F1 if using the Visual Studio keymap) or use the View External Documentation action (Shift+F1) directly to navigate to locally installed documentation, or to Unity’s hosted docs if not available locally.

Quick Documentation popup

We’ve added a couple of new features in this release designed to speed up working with simple boilerplate code – field serialisation. Firstly, we’ve added a new context action to the Alt+Enter menu to convert an auto-property to a property with a serialised backing field.

Context Action to convert auto property to property with serialised backing field

Secondly, we’ve made it very easy to quickly add a  [SerializeField] or [NonSerialized] attribute to a field in a MonoBehaviour  class. And of course, if you add both, Rider will notice and mark the [SerializeField] as redundant, which you can easily remove with another Alt+Enter.

Mark field as serialised context actions

We’ve also improved the relevance of Unity’s event functions in as-you-type code completion, making it much easier to find the function you want. Previously, when starting to type a method signature inside a MonoBehaviour, Rider would list potential return types first. Now, Rider will try to match event functions before anything else, adding them to the top of the list.

But what we really like doing is finding issues early – before you see them in the Unity editor console, or even better, before they fail at runtime. We’ve added a couple of inspections to help reduce the amount of time you swap between Rider and Unity. We’ll tell you, as you type, when you have an incorrect signature for a method marked with a Unity attribute. And of course, a quick Alt+Enter will fix up the signature for you. And all before switching back to the Unity editor, hitting play and waiting for the console messages.

Incorrect method signature inspection

Furthermore, we’ve added inspections that recognise when a Unity attribute is incorrectly applied to the wrong target, such as using [SerializeField] on a class or method – something that doesn’t even get reported at runtime, but will silently fail to do what you expect, leaving you scratching your head wondering why.

Invalid attribute usage inspection

External class libraries

This release improves our story with external class libraries, too. We’ve added a Unity class library project template, to make it quick and easy to generate a class library that references UnityEngine.dll. And once the project is generated and the library added to the main Unity project, Rider will automatically use pdb2mdb to enable debugging of external class libraries.

Unity class library template dialog

We’ll give more details about working with and debugging external class libraries in a follow up post.

Integration

We’ve also made a number of major improvements to our integration with the Unity editor and generated projects. For example, we’ll now recognise custom references from the   mcs.rsp file, so no more red code due to unrecognised assemblies. Rider will also regenerate the project files on initialisation, to make sure the files are always up to date and in sync with the asset view.

This release also sees a significant improvement in being able to run certain types of unit tests. While we are not yet able to run all types of unit tests (anything that requires Unity specific APIs still needs to run in the Unity editor process), we have fixed an issue that caused normal tests to fail with an exception when run from Rider. This is due to Unity 5.6 and above shipping a custom build of nunit.framework.dll. This build has changes that allow it to run correctly in the Mono environment that runs the Unity editor, but unfortunately, these changes make it incompatible with third part test runners, including Rider and ReSharper. This release of Rider fixes the issue, by running the tests with a compatible, but standard build of nunit.framework.dll (don’t worry – the tests will still use the custom build when run inside Unity). We are working on improving unit testing further in future releases.

Finally, Rider provides extra configuration options for the version of the framework we use. We’ve previously been able to override the target framework version of referenced base class libraries to workaround differences in the references the IDE sees, and the ones that Unity compiles with. And with this release, we’ve split the option into two – you can now set it differently for your .NET 2 and .NET 4 projects.

Rider page in Unity preferences

Fixes

And of course this version includes a number of useful fixes to existing functionality, too. Most notably with the debugger, which fixes a couple of annoying issues with not being able to view local values in coroutines and tasks, and not breaking on user unhandled exceptions.

More details of all of the fixes and improvements in Rider 2017.3 can be seen in this GitHub Milestone (yes, it’s Open Source!). There’s a lot of new stuff in here, and we’d love to hear your feedback. You can download Rider here (remember Unity support is built in, so there’s nothing else to configure), and raise issues, feature requests or otherwise leave feedback either on GitHub, or in YouTrack.

And just wait till you see what we have planned for the next version!

This entry was posted in How-To's and tagged , . Bookmark the permalink.

11 Responses to Rider 2017.3 and Unity

  1. George cook says:

    Awesome work guys. Thank.

    I’m seeing that u ity will hang when using assemblies if rider is attached. I detach rider and unity comes back to life. Raised a big with unity but wondering if it’s a rider bug.

  2. Jefferson B says:

    Hey guys, thanks for the awesome improvements in the Unity integration, been using Rider for the past months and really liking almost everything.

    One issue I constantly have however: Indexing takes AGES for me. When fresh opening our Unity Project (about 2400~ script files) rider hangs on the “Scanning files to index…” for 4+ hours at times.
    I don’t think this is the expected behavior and would very much like to see if we can do anything to improve this. Having Rider and/or the project in SSDs doesn’t change anything.

    Any ideas? :)

    • Matt Ellis says:

      That doesn’t sound good. Would you be able to create a YouTrack issue with some details on the project (e.g. size of Assets folder, simple file count, etc.), and attach logs, please? You can use the Help → Collect and Show Logs feature to zip up the logs, and just attach that to the issue. We’ll take a look and see what’s going on. Thanks!

  3. Jefferson B says:

    Sure thing Matt.

    Should I wait for the project to finish indexing or do you want the logs mid-indexing?

  4. VVEthan says:

    This is awesome, thank you so much for the Unity focused improvements — its what our dev team bought Rider licenses for!

  5. dereklu says:

    is there anyway to disable unity’s assembly not refrence nunit.framework.dll when i open it with rider? we build our project in the CI,but sometime we just make a mistake that import the namespace Nunit,but it is not compile problem in the UnityEditor, it is so annoying..

    • Matt Ellis says:

      It’s actually Unity adding the reference to nunit.framework.dll, rather than Rider. Starting with Rider 2018.1, we no longer do anything with the nunit reference, as we now have the ability to run tests directly in the Unity editor process. So Rider will not be doing anything to remove the reference.

      Perhaps you could add your own plugin to Unity that would post process the generated project files and remove the reference?

Leave a Reply

Your email address will not be published. Required fields are marked *