Dev Team blog

One of our customers was seeing crashes of Visual Studio and ReSharper, because of what looked like an out of memory situation. Visual Studio with ReSharper would crash loading a large solution. We expected a memory leak, or fragmentation of the Large Object Heap (LOH). But that was not the case. In this post, let’s look at an interesting issue that we investigated (and resolved) during the past

Today we are introducing a new type of dataflow code analysis in ReSharper and Rider. We’ve gathered some statistics (by exploring the IL metadata of a large number of NuGet.org packages with an OSS license) and noticed that int is one of the most commonly used types for local variables. That's why this new analysis tracks the usage of values of the int type in your programs. It tracks the flow o

This blog post is a part of a series that covers various technical challenges that we had to resolve during the migration of the Rider backend process from Mono to .NET Core. By sharing our experiences, we hope to help those who are in the same boat. So far in this series, we’ve looked at: How Socket Error Codes Depend on Runtime and Operating System How Sorting Order Depends on Runtime and

This post is the first part of a blog post series that covers different technical challenges that we had to resolve during the migration of the Rider backend process from Mono to .NET Core. By sharing our experiences, we hope to help out those who are in the same boat. There’s too much to share in one post, so we will make this into a series of posts. In this series: How Socket Error Codes De

Many Rider users may know that the IDE has two main processes: frontend (Java-application based on the IntelliJ platform) and backend (.NET-application based on ReSharper). Since the first release of Rider, we’ve used Mono as the backend runtime on Linux and macOS. A few years ago, we decided to migrate to .NET Core. After resolving hundreds of technical challenges, we are finally ready to present