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):
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!
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 F#, plugins, Rider
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).
Rider comes with a built-in terminal. It provides a command line right inside of our IDE and lets us do things like running .NET Core commands (for example with Entity Framework core), running Git commands, etc. There’s no switching windows (and mental focus) when we need to perform a quick command line task. In this post, let’s look at a few tips and tricks around Rider’s terminal.
The terminal tool window
We can open the terminal from the View | Tool Windows | Terminal menu (or double-shift and type terminal, or just Ctrl+Alt+1 / ^⌘1). It will open a new tool window running our system’s default shell, pointing at the solution directory. This gives us direct access to all files in our solution. We can run commands against them, switch into a project directory (
dotnet commands, …
Note: make sure to check out our series about Rider’s debugger!
Lambda expression breakpoints
When placing a breakpoint on a line with multiple statements, for example where one is a lambda expression, Rider will ask us whether we want to pause program execution on the entire statement, or just on the lambda:
Pattern matching with generics (spec) is another great topic for our blog series about support for C# 7.0 and C# 7.1 in ReSharper (and Rider)! Using pattern matching, we can combine a type check with a cast, removing some language ceremony. Let’s see how ReSharper can help us with its inspections, quick-fixes and context actions.
In this series (we will update the table of contents as we progress):