On March 28th we held a special evening of Rider talks at JetBrains Munich office. We would like to thank everybody who was able to join us and make the event a great success.
For those who couldn’t join us in person, we are happy to share the following recorded talks in the playlist below: A Lap Around the Latest Rider 2017.3, .NET Performance Issues and Optimizations in Visual Studio / Roslyn / ReSharper / Rider, and Debugging Tips & Tricks in Rider. Full talk descriptions can be found below.
The latest build of Rider 2018.1 EAP brings joy to F# developers by adding file ordering to F# projects! Files are now ordered in dependency order, and we can drag-and-drop to reorder files in our project. Let’s have a look!
The F# compiler, when invoked using MSBuild, will determine file order based on <Compile> entries in our .fsproj file (which is just like any other project file). The latest Rider 2018.1 EAP will display files in our project in the same order. We can also re-order files in F# projects, helping us structure our project.
In the Solution Explorer, we can drag-and-drop F# files (click and hold, drag the mouse), and control the file order that will be observed by MSBuild and the compiler:
Last time, we looked at how Rider 2018.1 introduces a new Unity editor plugin which allows us to build deeper integration with Unity. We saw how we can now control play mode and step single frames without having to switch away from Rider.
In this series:
In this post, we’ll take a look at another new feature that will also help reduce the amount of time you spend switching between the Unity editor and Rider – the new Unity log viewer.
This tool window, which is only available when we are connected to the Unity editor, brings Unity’s Console window right into Rider. It will be updated as events are logged in Unity, and allows filtering based on category (error, warning or message). You can also show and hide events based on when they were logged – in play mode, or edit mode.
In our previous post, we looked at how we can specify ReSharper’s inspection severities inside our EditorConfig file. In this post, we will see how ReSharper and Rider integrate with StyleCop configurations.
In this series:
In the same way as ReSharper handles Roslyn coding conventions, it will also handle StyleCop rules. First, let’s make sure that we have enabled Read settings from editorconfig and project settings under Options | Code Inspection | Settings (in Rider, this is under Editor | Inspection Settings). After we’ve also enabled StyleCop support under Options | Code Editing | General Formatter Style (in Rider, this is under Editor | Code Style), all StyleCop configuration files will be evaluated and the ReSharper code style settings will be adapted accordingly:
A fresh build of Rider 2018.1 EAP just landed, adding Entity Framework support! Rider adds functionality to enable migrations, add a migration, get migrations, update the database and more! On Windows, Linux and macOS! Let’s check this out, shall we?
After installing the EntityFramework NuGet package, we can initialize Entity Framework in our project from the project context menu, under Tools | Entity Framework | Initial setup.
After confirming we want to initialize Entity Framework, Rider will add the necessary entries into our App.config or Web.config file: the entityFramework configuration section is registered and added, as well as a database connection. Continue reading
In our previous post, we looked at how we can specify ReSharper’s inspection severities inside our EditorConfig file. In this post, we will see how ReSharper and Rider integrate with Roslyn conventions.
In this series:
When we are in collaboration with folks that don’t have ReSharper or Rider installed, it makes sense to use Roslyn conventions in our EditorConfig file as well. Since ReSharper 2017.1 we supported reading most of the Roslyn formatting conventions and adjust the effective ReSharper settings accordingly. In ReSharper 2018.1 EAP and Rider 2018.1, we extend our support by the following Roslyn language conventions including their severity:
dotnet_style_qualification_for_fielddotnet_style_qualification_for_propertydotnet_style_qualification_for_methoddotnet_style_qualification_for_eventdotnet_style_predefined_type_for_locals_parameters_membersdotnet_style_predefined_type_for_member_accessdotnet_style_require_accessibility_modifierscsharp_preferred_modifier_ordercsharp_style_var_for_built_in_typescsharp_style_var_when_type_is_apparentcsharp_style_var_elsewherecsharp_style_expression_bodied_constructorscsharp_style_expression_bodied_methodscsharp_style_expression_bodied_propertiescsharp_style_expression_bodied_accessorscsharp_prefer_bracesNote: we will add support for Roslyn naming conventions in a future version of ReSharper. Continue reading
In our previous post, we looked at how we can maintain a consistent code style with the newly added formatting inspections in ReSharper and Rider. In this post, we will look at the different ways to configure inspection severities.
In this series:
Starting with ReSharper 2017.1 it was possible to define ReSharper formatting style settings directly inside the EditorConfig file. This allows us to keep our coding style settings in a central place, no matter what IDE other developers in our team are using.
With ReSharper 2018.1 EAP and Rider 2018.1 EAP, we improve our support for EditorConfig to read even more ReSharper settings from the EditorConfig file, including inspection severities and non-formatter code style settings. First, we need to enable this feature in Options | Code Inspection | Settings:
One of our big themes with Rider’s Unity support is to reduce how much time you spend context switching between Rider and the Unity editor, and Rider 2018.1 introduces some new features that are designed to do just that.
Our new secret sauce is that we’ve improved our existing Unity editor integration. We’ve added a much smarter editor plugin that opens up two way communication between Rider and the editor. This means the editor can talk to Rider, to tell it to open a C# file that’s just been double clicked, but even better, it means Rider can now talk to the editor, and tell it to do things, such as switch to play mode.
In this series:
ReSharper (and Rider) have always provided a wide range of code inspections to notify us about redundancies in code, potential code quality issues or common practices. In the next 4 blog posts, we will dive into a bunch of new features related to that: How can ReSharper help us to further increase readability? How does it integrate with other approaches in the .NET ecosystem? And what are the different ways of configuring that?
In this series:
Formatting inspections have been one of the most requested features from our users. So let’s take a very close look at them.
Note: these inspections are also available in Rider 2018.1.
With ReSharper 2018.1 EAP, we’re adding an initial set of 38 formatting inspections for C#. We can selectively enable them and assign an individual severity under Options | Code Inspection | Inspection Severity | C# | Formatting:
Depending on the solution, our code base might have hundreds of certain formatting violations, which would become too noisy to activate them. Potential issues like different indent sizes across methods, different case-label indents in switch-statements or missing line breaks are decreasing readability in some sense but can occur way to often.
We would like to elaborate on more important formatting inspections, which – we think – greatly decrease readability or may influence our conception of the code.
Continue reading
Our latest EAP builds of Rider 2018.1 include improvements in navigation. Let’s explore some of the new features for the Find Usages and Go To actions, such as getting results in a tool window (with previews!) as well as this being executed asynchronously – making things snappier.
Rider now has improved support for getting multiple results for Find Usages. For example, when we want to find where a certain view model is used in our solution, we can Find Usages by pressing Shift+F12. If a single usage is found, Rider will navigate us to the usage directly in the editor. When multiple usages are found, we can explore them in a separate tool window.
