Getting started with Rider and Unity

We recently released Rider, a new IDE for C# and .NET developers. It runs cross platform, on Windows, Mac and Linux, and comes with built in support for Unity – code completion for event functions, inspections and quick-fixes for Unity code, support for shader files and more. Today, we’re going to take a look at how you get started, and how Rider will help with your Unity code.

Here’s a quick overview video that shows Rider in action with Unity code. Read on for more details.

If you haven’t encountered Rider before, it’s a new IDE for .NET and C#, based on the best bits of ReSharper and IntelliJ IDEA. ReSharper provides the C# language engine, with code completion, navigation, find usages, thousands of inspections, quick-fixes, refactorings and more, while IntelliJ provides the rich, cross platform user interface – editor, debugger, test runner and so on. You can download a free 30 day trial now, and get started right away.

Getting started

Getting started with Rider and Unity is nice and easy. Rider has Unity support built in, and the very first time you open a Unity solution it will automatically configure Unity to use Rider as the default editor for C# scripts and shader files. Once done, double clicking a C# script or shader asset will open the solution in Rider.

Note that you can also do this manually, through the External Tools page of Unity’s *Preferences* dialog. The initial Rider 2017.1 release required this to be done manually. This has been fixed in the recently released Rider 2017.1.1. Install Rider using the Toolbox App to make it easy to stay up to date.

When Rider first opens your Unity project, it will install a small Unity Editor plugin into your project. This plugin improves integration between Unity and Rider, such as speeding up the time to open a C# script at the right line, making sure that all necessary references are added to the generated C# project files, and making debugging the Editor easier.

Unity plugin installed notification

It also adds a Rider page to the Preferences dialog with some options. This plugin should be committed to your source control, and Rider will automatically keep this file up to date when new versions are available (this behaviour can be disabled in Rider’s options). More details can be found here.

Rider preferences page in Unity

Furthermore, when a Unity project is opened, Rider will check its own auto-save settings, and recommend changing behaviour to work better with Unity.

By default, Rider will automatically save files when you switch to another application or when Rider is idle. This is usually a great way to work, but it can have a negative impact with Unity projects, as it will cause a recompile which can reset game data if you’re in play mode.

To prevent this, Rider suggests disabling auto-save, so you have to be explicit about saving your files. Simply click the link in the notification, and Rider will make the changes – and even let you know what was changed. (And don’t worry, Local History keeps you covered, keeping track of all unsaved changes in the background.)

Rider notification to disable auto-save

Features – code completion, inspections and more

Rider ships with knowledge of the Unity API, and will mark classes, methods and fields that are implicitly used by Unity directly in the editor.

Unity methods and fields marked with icon in editor gutter

And of course, Rider makes it easy to generate Unity event functions, either using the Generate menu or simply by typing, with autocompletion.

Hovering over a method or method parameter will display the Unity documentation as a tooltip, or in the QuickDoc popup, calling out event functions that can be coroutines.

Unity documentation shown in tooltips and Quick Doc popup

Rider’s Solution Wide Analysis will allow Rider to find (amongst other things) public types and type members that are not in use. They will be greyed out, and you can safely delete them, knowing they’re not used in your code.

But Unity doesn’t work like that – there are classes, methods and fields that aren’t used by your code, but called and set implicitly by the Unity engine. Because they’re not used explicitly by your code, Rider would ordinarily mark them as unused, but deleting them would obviously cause issues with your game. Fortunately, Rider knows about the Unity API, and will mark these implicitly used types and type members as in use. Even better, it knows that a field value is set implicitly by Unity, but will still warn you if the value isn’t accessed in your code.

Warning that field is initalised by Unity but unused in code

Of course, if your event function is empty, Rider will still suggest you remove it, for efficiency.

Rider adds a number of Unity specific inspections and quick-fixes. For example, Rider will warn you against using an inefficient string literal comparison with the tag property, and will provide a quick-fix to rewrite this as a call to CompareTag.

Similarly, Rider will warn you if you try to use the new  keyword to create a new instance of a class deriving from MonoBehaviour or ScriptableObject. A quick Alt+Enter later, and Rider will fix this up to call gameObject.AddComponent<T>()  or ScriptableObject.CreateInstance<T>().

Because Rider knows about the Unity API, it can verify that all of your “magic methods” have the correct signature. It will ensure that all of your event functions have the correct signature, or it will remove the marker that shows that Unity will call the method implicitly. It will show warning highlights and a quick-fix will correct the method signature. Any unused optional parameters are highlighted, ready for removal, and a context action is available to change the return type to IEnumerable for methods that can be coroutines.

There are also inspections for the [InitializeOnLoad]  and [InitializeOnLoadMethod]  attributes, ensuring they have the correct method or constructor signatures, and Rider will grey out a redundant [InitializeOnLoad] attribute if the class doesn’t have a static constructor, with a quick-fix to either quickly remove the attribute, or create the constructor.

And Rider understands Unity’s colour types, too, showing the colour in the editor, and providing an Alt+Enter context action to pick the colour from a palette.

Colour highlights in the editor

One of the more powerful features of the ReSharper engine that powers Rider is the ability to add “references” to string literals. What this means for Unity developers is that Rider knows that the string literal arguments to methods like Invoke, InvokeRepeating, StartCoroutine and StopCoroutine are references to methods. So Rider can validate that the name is correct, and even better, offer code completion, directly in the string literal. And that’s just the start – these string literals take part in navigation, find usages and are updated when the method is renamed.

Code completion in string literals

Rider also introduces initial support for .shader files. ShaderLab content has more support than Cg sections just now, but we’re working on this for future releases. Shader files get syntax highlighting and simple word completion (aka “hippie completion”). ShaderLab content also gets syntax error highlighting, code folding, commenting/uncommenting, and brace matching, as well as recognising To Do items.

Shader file with syntax highlighting and code folding

Debugging

Rider makes it very easy to debug your C# scripts as they run in the Unity editor. Everything is already configured, and you just need to hit the Debug toolbar button, menu item or keyboard shortcut to attach the debugger to the running Unity editor. You can set breakpoints in the editor, step through your code, look at locals and watch values and evaluate expressions.

Debugging

And Rider’s advanced breakpoint editor allows you to enable or disable a breakpoint, set a condition or hit count, and also decide what happens when it’s hit – suspend execution, or continue, after logging a message or value. You can even remove a breakpoint after it’s been hit, or only enable it after another breakpoint has been reached – allowing for complex breakpoints in methods that are called frequently, such as Update, or chaining breakpoints in a complex bit of game logic.

Breakpoint editor

And more…

Of course, these are just Rider’s Unity specific features – there are plenty more features that will help you navigate, create and refactor your game logic. Rider has over 2,000 code inspections, over 1,000 quick-fixes, nearly 350 context actions and 50 refactorings.

It boasts rich navigation to jump straight to a type, find usages, go to derived or base classes. There’s unit testing support, code cleanup, integrated version control, Local History to save your code between commits, NuGet support (and we’ve made it fast), database tooling and more. It also has access to IntelliJ’s rich plugin system, with over 800 plugins already available, from Markdown support to VIM keyboard bindings (the Key Promoter X plugin is fantastic for learning keyboard shortcuts).

All of which adds up to a very rich and powerful IDE, aimed at C# and .NET developers, with Unity support built in. But the best way to find out how good Rider is, is to try it yourself. Download the full featured, 30-day trial version for Windows, Mac or Linux, and try it with your project today. And don’t forget about our Toolbox App, as a great way to manage updates, projects and other IDEs.

And finally, the Unity support is Open Source, on GitHub. If there’s a Unity specific feature you think Rider is missing, let us know!

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

35 Responses to Getting started with Rider and Unity

  1. Pingback: Dew Drop - August 30, 2017 (#2551) - Morning Dew

  2. Mike-EEE says:

    Someone there @ JB please knock some sense into the folks at Unity and get them to understand the value of interfaces and well-known contracts… and general .NET design principles while you’re at it. 😉

  3. Dev says:

    That’s just C# 2 support with extra steps!

  4. Yuri says:

    BS, just give us net core 2 support already!!!
    VsCode is tenting me!

  5. Julo says:

    Please make it possible to run EF6 commands (add-migration, update-database …) otherwise it’s useless for a lot of folks on ASP .Net

  6. Greg says:

    Is the debugger crash with Rider and Unity fixed yet? I had to uninstall Rider and go back to VS because of it.

    • George Cook says:

      you got an issue number? I’ve had no crashes debugging for months, across Unity versions 5.6>2017.2 beta, and God knows how many Rider versions. Hope that helps.

  7. Andrew says:

    Can you attach the debugger to standalone builds of your game? This is something that visual studio makes very easy and it’s extremely useful.

  8. Stepan Stulov says:

    How does syntax highlighting granularity compare with MonoDevelop and/or Visual Studio? I see some elements of different nature having the same color. Thank you for the hints.

    • Matt Ellis says:

      The ShaderLab part of the .shader file is highlighted by parsing the contents of the file and building a syntax tree. We then use this tree to know how to classify the file, as number, string literal, keyword or comment. We don’t have any other classification types yet (variable reference is one that will come in the future).

      As of Rider 2017.1, the Cg/HLSL blocks are highlighted by simple keyword matches, and there are known inaccuracies in the syntax highlighting here. For Rider 2017.2, we’ve written a parser for the Cg/HLSL language, and we’re now using this for syntax highlighting (it’s not yet complete, as Cg/HLSL is a complex language, so we’re not yet using it to show syntax errors, or anything other advanced features). Rider 2017.2 will be much more accurate with highlighting.

      However, there are bound to be differences between the implementations, as classification is somewhat open to interpretation (should the “Front” in a ShaderLab “Cull” command be treated as a value, or as a keyword?). That said, if there are things that are obviously wrong, or just plain weird, let us know, send us a repro, or a screenshot and we’ll take a look).

      • Stepan Stulov says:

        Hi, Matt. Thank you very much for the detailed explanation. I apologize for not being clearer by I meant C# syntax highlighting granularity. That’s a known problem with Visual Studio family and one of the main reasons for me to stay with MonoDevelop despite all of its horrible bugs. I’d jump ship any moment, but from what I see Rider has the same limited granularity: method arguments, properties, methods all have the same color. Would you mind giving us a comment on that? Thank you very much!

        • Matt Ellis says:

          It depends on what colour scheme you use. If you use “Visual Studio Light” or “Visual Studio Dark”, then yes, many identifiers are coloured the same. This scheme is designed to mimic Visual Studio, to be familiar and comfortable to new users coming from Visual Studio. Looking back at the screenshots above, I think I was using “Visual Studio Light” here.

          However, you can use the “ReSharper Light” or “ReSharper Dark” colour schemes. These have more semantic highlighting – method names, fields, classes, interfaces, etc. have different colours.

          And of course you can edit the colours as well, in Preferences → Editors → Color Scheme → Language Defaults. There are a lot of different categories here, such as “local variable” and “local variable (mutable)”, or “method” and “extension method”. You should be able to configure it just how you like.

          • Stepan Stulov says:

            Hi, Matt. I finally got to try the Rider. Things are looking pretty good. However I don’t see any specific C# coloring, only “Language Defaults”. As an example to what I’d love to see colored differently is preprocessor directives (#region, #if, #elseif, #else, etc.). I prefer them to be very close to the color of the background to make sure they are there but not distracting. In the current color scheme logic #region is treated as a keyword (which it isn’t), and region’s own name is treated as something else too. Or am I missing something? Cheers!

            • Matt Ellis says:

              Yes, C# uses the Language Defaults section (showing its heritage as it was originally a C# IDE). Most things are properly configurable via this page, but you’re right, Rider does classify preprocessor directives as keywords. I’ve created an issue for this: RIDER-13163

          • Stepan Stulov says:

            Hey, Matt. Thanks for opening the issue.

            Another thing I had problems finding is camel/pascal case subword navigation. In MonoDevelop I can do ctrl+arrows to jump whole words and alt+arrows to jump between subwords in a properly camel-cased word. This is golden.

            One more thing is I didn’t find C# specific templates/code snippets. Here is a desired scenario: I define a code snipped with a number of parameters for example $type$ and $name$ (whichever special symbols are used). For each such parameters I can specify whether it’s an identifier (so its restricted to what symbols may constitute its value) as well as a default value. Additionally there is a set of embedded parameters like for example $end$ for where the cursor will be when the snipped is completed. There are also so called “surround” snippets, that will work with a selected text and surround it with elements, like the $region snippet.

            These are the things I’m automatically missing in Rider having been (way too) long with MonoDevelop+Unity. For now Rider looks ridiculously good but just this LITTLE BIT not there for me to jump ship.

            Hope this helps.

            • Matt Ellis says:

              Rider already has support for camel hump navigation.

              Make sure you have “Use camel humps” selected in the Editor → General → Typing Assistance preferences page. This should change the behaviour of the “Move caret to next/previous word” actions to use camel humps. There are additional “camel hump” actions if you don’t want to change the default behvaiour – go to Keymap in preferences and search for “camel”.

              Rider also has support for Live Templates, just as you describe – it exposes the same functionality from ReSharper. Unfortunately, right now, we don’t have a way to edit the templates in Rider. You can vote for this issue to track this feature request: RIDER-548

  9. Jason says:

    Is debugging for external dlls supported?

    • Matt Ellis says:

      Yes, as long as the external .dlls have Unity/Mono compatible .mdb debug files. On Windows, the latest nightly builds of Rider 2017.3 ship with pdb2mdb, and will automatically convert any .pdb files added as assets into .mdb files.

      On Mac/Linux, the Mono compiler should be used to produce .mdb files. Modern installs of Mono will use Microsoft’s CSC C# compiler, and generate “portable” .pdb files, which are not compatible with either Unity’s Mono or the pdb2mdb executable.

      You can tell Rider to use Unity’s Mono toolset for compiling, by selecting the Unity versions of the Mono executable and xbuild from the drop downs in the Preferences → Build, Execution and Deployment → Toolset and Build. This will compile with Unity’s version of the Mono toolset, and generate .mdb files. This will however, limit you to C# 6.

  10. George cook says:

    I’ve tried all night to get rider to debug a unity 2017.3 build. It just won’t do it. Built with relevant settings and debug symbols. What am I doing wrong? Really need build debugging. !

    • George cook says:

      Resolved it. For anyone else interested you need to go to the debug menu and select attach to unity. The option from the debug profiles doesn’t work. Shame it’s not possible to run the credit automatically thoguh as you end up sweating to alt tab and start in time.

      • Matt Ellis says:

        Hi George. I’m not sure what you’ve been struggling with here. The Unity support in Rider should add an “Attach to Unity Editor” run configuration, and have it automatically selected – you should see it in the right side of the toolbar at the top of the window. Just hitting the debug button next to it should attach you to the currently running Unity Editor instance.

        What were you seeing that was different?

      • Stepan Stulov says:

        Hey, George. I believe the problem may be the slightly confusing name. By hitting the “Attach to Unity Editor” you don’t initiate the debug session, you actually just select the profile. You need to hit the bug button to the right of it. Could this be the problem? Cheers

  11. Stepan Stulov says:

    Suggestion for when renaming private fields with [SerializeField] or public fields within a Unity script: OPTIONALLY insert [FormerlySerializedAs(“”)] attribute with the previous name. This will make life easier when renaming fields of MonoBehavior or a ScriptableObject of which there are a jizillion instances. Hope this helps.

    • Matt Ellis says:

      Yes, this is a request we’ve had before. We’re hoping to add something in the near future. See #54 for renaming fields, and also #55 for encapsulating fields.

  12. George Cook says:

    How does one build for release? i.e. do the same build that unity does from “build and run”? Debugging the #if UNITY_EDITOR mishaps that asset store developers have made would be much more pleasant.

    • Matt Ellis says:

      Rider will compile the project and find normal compilation errors, but a full build still requires switching to Unity. Could you describe your scenario a little more? There might be something else we can do to help.

  13. Manu says:

    macOS related question: How do you setup Unity, if you use the Jetbrains Toolbox? Since the executable of Rider is within the Jetbrains Toolbox package.

    A workaround currently is to open all .cs files directly with Rider and use “Open by file extension” in Unity, but I dislike that, since my main editor is sublime for quick file viewing.

Leave a Reply

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