Since we first released the Early Access Preview (EAP) of Rider, our cross-platform IDE, we’ve been hard at work improving many aspects of it. We spent quite some time improving visible (and invisible) aspects of the editor. Let’s look at some of the updates to code highlighting, folding and code completion.
In this post, we’re going to look at how ReSharper 2016.3 can help you unit test your .NET Core applications and libraries.
Sadly, before we can look at this, we have to deal with the confusing issue of what versions of .NET Core are supported.
TL;DR: ReSharper 2016.3 works with .NET Core projects in Visual Studio 2015 and Visual Studio 2017 “RC”, but unit testing only works in project.json based projects. The IDE interface to
dotnet test was rewritten for the .csproj based projects in Visual Studio 2017 “RC” and only just documented. More details at the end of this post.
Unit testing in .NET Core
Right, let’s take a look at unit testing a .NET Core app or library.
Since our first public Early Access Preview (EAP) for Rider, we’ve been hard at work improving our cross-platform IDE for .NET development. Rider helps keeping a consistent code style throughout our code base, applying style settings that are based on widely accepted conventions and best practices. Since recently, we support code style settings, making it possible to set our personal our team code style preferences.
Code style settings
From Rider’s settings (Ctrl+Alt+S), under Editor | Code Style we can specify the style rules our IDE should follow when we’re writing or generating code, or when a refactoring is executed. For example, we can specify whether Rider should use
var or explicit types.
When we released ReSharper 2016.3 (and earlier this week, ReSharper 2017.1 EAP), we introduced initial support for C# 7 and VB.NET 15. For example, ReSharper now understands binary literals and digit separators, as well as local functions with several inspections. We’re far from feature complete, but want to look ahead at what’s coming in terms of new programming language features and what we are working on for ReSharper (including some of the challenges building out those features). Here goes!
In this post:
Last week we launched an Early Access Program for ReSharper Ultimate 2017.1. We hope that you’ve already downloaded the build and discovered some of the new features. Today we’d like to take a closer look at the most notable updates, which relate to the following product areas:
We are glad to announce the start of the Early Access Program for ReSharper Ultimate 2017.1, the first major update of this year that we expect to release this spring. Since the beginning of the year, we’ve been working hard on resolving compatibility issues with Visual Studio 2017, implementing support for C# 7, TypeScript 2.2 and Angular 2 templates syntax. We also enhanced code formatting rules and introduced initial support for EditorConfig.
Download ReSharper Ultimate 2017.1 EAP 1 and taste the new features.
You don’t need an active subscription to use the EAP, but please be aware that you may face unexpected performance issues or bugs. And if you encounter any, don’t hesitate to share your feedback with us in the comments section below and in our tracker.
Please, expect another blog post early next week with details about changes in the first EAP build.
Since we opened the public Early Access Preview (EAP) for Rider, we have shipped a few updates that contained bugfixes as well as new features. We received great feedback from all of you, with one big request: “Make it possible to open multiple solutions at once”. Without further ado:
Let’s see how this works and how you configure Rider’s behavior.
If you are a long-term user of dotTrace Timeline Viewer, you’ve likely noticed some UI changes in dotTrace 2016.3. What has changed exactly and, more importantly, why were these changes made? Read on to find out.
While JetBrains is still working on a full SDK for Rider, it is already possible to make a plugin for it – at least for the front-end part. As Rider is built on IntelliJ Platform, just like WebStorm and IntelliJ IDEA, we can write plugins for it using the IntelliJ plugin SDK.
A good example would be the REST client we have in Rider. Sure, it’s built-in, but it’s a plugin providing some awesome functionality! One could build, for example, a NuGet package explorer – just showing package contents is not something that would need the back end. Want to add an image editor into the IDE? Create a context menu action that converts a JDBC database connection string to a .NET connection string? A tool window showing Dilbert comics? All fine examples that can be built as a front end plugin!
But front end? Back end? Before we look at a simple example, let’s see what Rider is made of.
Posted in How-To's
Tagged plugins, Rider