Rider 2018.1 introduced deep integration with the Unity Editor, allowing you to run unit tests, view Unity console log entries and control play mode, all without leaving Rider. In our third post looking at Rider 2018.2 and Unity, we’ll look at what’s new in Editor integration.
In this series:
- Unity Package Explorer
- Assembly Definition Files
- Unity Editor integration updates
- Unity specific code analysis
Installation and first use
The easiest way to get started with Rider and Unity is to load an existing solution, at which point we’ll automatically install a plugin into your Unity project. When you switch back to Unity, the plugin initialises, sets Rider as the default external editor and you’re all set. The plugin makes sure the generated C# projects are compatible with Rider, and will set up the inter-process communication that lets Rider run tests, view logs and so on.
But there’s a little bit of a chicken and egg scenario here. What happens when there aren’t any solution files? Unity generates these files, and makes sure they’re up to date when you double click a C# file. But they’re not usually checked into source control. So how do you open a project without solution files?
Of course, once Rider is set as the default external editor in Unity, you can double click a C# file and Unity will open Rider for you. But we also received feedback that users were trying to open a Unity project using Rider’s Open Folder feature. This is mostly intended for working with web files, and not C# projects, which require MSBuild files. Without important context from project files (e.g. target framework version, references, etc.) Rider can’t show the C# features we all know and love, such as code completion or inspections, and this was understandably leaving users frustrated.
The good news is that we’ve addressed this in Rider 2018.2! If you try and open a fresh Unity project as a folder, Rider will now notify you that Unity and C# functionality is unavailable until the project is reopened correctly. It will also prompt you to install the plugin. Once you’ve clicked the action link, Rider will install the plugin and then prompt you to switch back to Unity, at which point Unity will load the plugin, set the default external editor and generate the project files. You can now reload the solution correctly.
(Of course, you can also set Rider as the default external editor in Unity’s preferences – recent versions of Unity will recognise when Rider is installed and automatically add it to the list of available editors. Once selected, double clicking a C# file will generate the solution, open it in Rider, and then the plugin is automatically installed.)
One of the cool features of Rider’s deep Unity integration is the ability to capture Unity’s Console log messages and bring them into Rider’s UI, with parsed, clickable stack traces. We’ve made a couple of nice updates in this release.
Firstly, we’ve added a text filter. Just start typing in the search field at the bottom of the window, and we’ll narrow down the list by only show matching items. Hit enter to change focus to the list and navigate with the cursor keys.
And if there are too many log entries? Well, you can now collapse similar items, using the toggle button in the toolbar. Once selected, Rider will only show a single item, with the number of merged items shown in brackets at the end of the message.
And finally, we can now open editor and player log files in Rider’s editor. Simply open the options menu in the Unity log viewer tool window (the cog in the top right of the tool window) and select Open Unity Editor Log or Open Unity Editor Player Log. Note that these log files are the Unity editor’s own logs, or logs from a standalone player, rather than the messages logged to Unity’s Console.
Working with class libraries
With the advent of Assembly Definition Files, Unity now has a story for splitting a solution up into separate assemblies, with the architectural and build time advantages this gives. But we know that there are still a lot of Unity developers who create a separate solution for class libraries that are then added as binary references to a Unity project. Wouldn’t it be nice if all those lovely Unity project integration features were available to these class library projects? Well, now they are!
If you have a class library project, with solution files living in the root of the Unity project (in the same location as the generated solution file), Rider will now enable the same rich integration features for class library projects.
This means you’ll get the log viewer, the play/pause/step buttons to control Unity’s play mode, and also automatic Attach to Unity Editor and Attach to Unity Editor and Play run configurations, to make it very easy to attach the debugger to the Unity editor.
And best of all, it will work even if you have the class library and the generated solutions open at the same time!
Control when to reloading assemblies
Unity is designed to have a tight feedback loop. Whenever a source file changes, the underlying assemblies are recompiled and reloaded. This works great for immediate feedback, but can be annoying when you’re in play mode – you’re busy play testing a scenario, and a modified file causes everything to reload and lose state. It can be very frustrating.
Unity 2018.2 added an option in the General preferences page to control what happens when scripts change during play mode. We liked it so much, we’ve brought it to earlier versions of Unity. The Rider page in Unity’s preferences dialog will now allow you to prevent assembly reloads during play mode, or reschedule them for after play mode, or to stop play mode straight away and recompile.
This is very useful when used together with Rider’s background refresh, which notifies Unity when a file has changed, causing a recompile. And you’ll also be pleased to hear that this release of Rider continues to fine tune the background refresh, making it a little less aggressive in when it causes a recompile.
Even better, the implementation for the lock assemblies feature came from an external contribution (yes, the Unity support is open source and has up-for-grabs issues!). Congratulations and thanks to Jurjen Biewenga! 🎉
Those are the main new features for editor integration in Rider 2018.2, but that’s not everything. There are also a few more minor updates, although some are no less important. For example:
- Rider now understands references added in csc.rsp files – Roslyn compiler response files. When generating the project files, Rider has previously looked for references and C# defines from mcs.rsp, smcs.rsp and gcms.rsp files and added them to the project file. This release adds similar support for csc.rsp files used by the latest C# compiler.
- We’ve reduced the number of times that generated project files are written to disk. This means that we reload the project less frequently, and although Rider is very quick at reloading (and doesn’t prompt you!), doing no work at all is always faster! It also makes much more of a difference for projects using Unity packages, which can end up having tens or even over a hundred projects.
- We’ve reduced the time taken when initialising the Unity plugin, to help improve that feedback cycle. We’ll be doing more work on this in coming releases.
- And finally, we’ve fixed a few other bugs and exceptions (see the full list for 2018.2, 2018.2.1 and 2018.2.2), the most important of which was a nasty crash with older versions of Unity. Other highlights include once again correctly setting LangVersion on older version of Unity, disabling the plugin in batch mode, and no longer unnecessarily install the plugin every time you open a project. Sorry about that!
As you can see, we’ve put a lot of effort into integrating Rider well with Unity, and we’re not done yet. In our next post, we’ll take a look at the new Unity specific inspections in Rider 2018.2.
If you have any suggestions for other features you’d like to see in Rider, please let us know. And in the meantime, please download Rider 2018.2 today, and give it a go (and don’t forget about the 30 day trial version)!