Configuring code formatting from code selection with ReSharper

In our previous posts, we looked at a few examples of the various improvements we made to the code formatting engine in ReSharper 2017.3 EAP and Rider 2017.3 EAP.

While we now have great control over how our source code is formatted, it may be like an airplane cockpit with too many options. In this post, we’ll look at the easiest way to tune the code formatting engine to our liking!

This post is part of a series around changes in the ReSharper and Rider code formatter:

Figuring out which code style settings apply to a block of code

With all of the existing (and new) code formatter changes, figuring out which settings apply to a block of code can be overwhelming. Fortunately, ReSharper provides an easy way to do this. Note that the following is currently only available in ReSharper, and is yet to be implemented in Rider.

Continue reading

Posted in How-To's | Tagged , , , , , , | 4 Comments

Aligning code in columns with ReSharper and Rider

In our previous post, we looked at how we can use different code styles for different blocks of code in ReSharper 2017.3 EAP and Rider 2017.3 EAP. In this post, we will look at some other improvements to the code formatting engine, such as aligning code in columns and a sneak preview of other changes coming in ReSharper 2017.3.

This post is part of a series around changes in the ReSharper and Rider code formatter:

Aligning code in columns

Another very popular group of code formatter feature requests was around aligning code. There were requests to align equal operands, to implement outdenting and make code using the ternary operator look nicer, and several other requests to make code more readable.

Continue reading

Posted in How-To's | Tagged , , , , , , , , | 20 Comments

Different code styles for different code blocks in ReSharper and Rider

In the previous post about the ReSharper and Rider code formatting engine, we saw an overview of new functionality that is available. In this post, it’s time to get our hands dirty and look at a couple of things in more detail!

This post is part of a series around code formatting changes in ReSharper 2017.3 EAP and Rider 2017.3 EAP:

Enable/disable formatter on selected blocks

One of the most-voted requests was to turn off code formatting on selected code blocks. Many users want to use different formatting styles for different blocks of code, or disable formatting altogether.

Continue reading

Posted in How-To's | Tagged , , , , , , , , | 6 Comments

Rider 2017.3 Early Access Program is open

We have just started up another Rider pre-release cycle: please feel free to download Rider 2017.3 EAP!

Rider 2017.3 Early Access Program is open

The first EAP build contains the following new features and bugfixes:

Continue reading

Posted in How-To's | Tagged , , , , , | 14 Comments

Code formatting engine updates in ReSharper and Rider

Over the past few ReSharper releases, we completely rewrote our code formatting engine. By doing this rewrite, we are able to iterate and innovate more rapidly.

In the latest ReSharper 2017.3 EAP releases, we have started to build on top of these rewritten foundations, guided by the most-voted feature requests in our issue tracker. Let’s start a blog series and look at the various improvements!

Continue reading

Posted in How-To's | Tagged , , , , , , , , , | 4 Comments

Analyzing performance of asynchronous .NET code with dotTrace

C# provides language-level support for asynchronous programming, allowing developers to create applications with a responsive UI with minimum effort. The introduction of the async/await syntactic sugar in .NET Framework 4.5 has also significantly eased writing asynchronous code.

One of the downsides of asynchronous code is it’s extremely difficult to profile it and analyze its performance. This is because, when an asynchronous method is executed, control is switched from the method to its caller and back, tangling the resulting call tree.

The good thing is that dotTrace 2017.3 dramatically simplifies the analysis of asynchronous code. It marks all async call nodes in the Call Tree and groups the corresponding await time and continuation code under that node. This means that you can quickly find all “parts” of an asynchronous call in one place instead of searching in different call stacks. Note that currently, this functionality is available only for the Timeline profiling mode.

To better understand how dotTrace 2017.3 treats asynchronous code, consider the following example (the code is shown on the left, the corresponding Call Tree on the right):
Async call. Call Tree

Continue reading

Posted in How-To's | Tagged , , | 2 Comments

ReSharper 2017.3 brings the debugger into the editor

While debugging, we often have to work with lots of information. We have the autos, locals and watches tool window to look at, code in our editor, … This overdose of information and switching between looking at code and at tool windows often messes with the mental context of the debugging session in our brains.

No more! With ReSharper 2017.3 EAP, we are proud to bring one of Rider’s features into Visual Studio: local variables, current line expressions and function returns are now displayed inside the editor! On top of that, we’re adding searchable DataTips!
Display variables from debugger in the editor

Continue reading

Posted in How-To's | Tagged , , , , | 44 Comments

Generate deconstructors with ReSharper

With C# 7 came language support for deconstructing tuples and other types.

ReSharper 2017.3 Early Access Program adds better support for deconstructors, including new inspections and generators. But before diving into how ReSharper can help with writing deconstructors, let’s cover what they are.

Continue reading

Posted in How-To's | Tagged , , , , , , | Leave a comment

Rider’s F# plugin is now open source

Back in May when we announced F# support in Rider, we told you we’d make F# plugin open source as soon as we are ready to accept contributions.

The day has finally come, and we have just made the F# plugin repository public.

For a quick summary, the F# plugin consists of a backend (ReSharper.Host plugin) and a frontend (IntelliJ Platform plugin) parts that are written in F#, C# and Kotlin. This may sound overcomplicated but thanks to an extensive use of NuGet and Gradle, setting up the development environment is pretty straightforward. Development is currently only supported on Windows although we expect to enable development on macOS and Linux soon.

There are currently no strict development guidelines, and if you’re up to it, you can grab pretty much any open F# issue on the Rider issue tracker although we have tagged some that should be easier to implement and are unlikely to require any infrastructural changes.

For more information on the internals of the plugin, requirements, build/run/debug guidelines, contribution workflow and known issues, check out F# plugin repository’s README.

To clear up any possible doubts, the Rider team will continue putting a lot of effort into F# support, and we’re looking forward to doing it in collaboration with the community.

Posted in How-To's | Tagged , , | Leave a comment

Using a custom shell with Rider’s built-in terminal

In a previous post, we’ve seen that Rider comes with a built-in terminal. It lets us do things like running .NET Core commands (for example with Entity Framework core), running Git commands, etc. There’s one thing we did not cover yet: customizing the shell that is used by Rider!

While the default shell in Rider works nice, many developers prefer to use their favorite shell. For example Windows users may want to use PowerShell or Cmder instead of the default, macOS and Linux users may want to use zsh. Good news: from the settings under Tools | Terminal, we can customize which shell is used by Rider (along with some other options).
Configure which shell to use in Rider

Continue reading

Posted in How-To's | Tagged , , | 2 Comments