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.
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.
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.
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.
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.
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.
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.
We’ll give more details about working with and debugging external class libraries in a follow up post.
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.
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!