ReSharper 2017.2

Along with the latest releases of ReSharper, we have made Code Cleanup part of the ReSharper Command Line Tools. These tools allow us to run several ReSharper features from the command line or as part of continuous integration. Two tools have been there for a while — InspectCode (which can run hundreds of ReSharper code inspections outside of Visual Studio) and dupFinder (which helps finding duplicate code in C# and VB.NET code). The new Code Cleanup command line will apply formatting code style preferences and other improvements such as file layout, removing redundancies, optimizing using,

Over the past days, we have been blogging about ReSharper support for C# 7.0 and C# 7.1. Today, let's conclude with a final part around how ReSharper understands the new syntax and constructs that C# 7.0 and C# 7.1 bring, and ties them into existing and new inspections, quick-fixes, navigation and refactorings. In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples Pattern matching with generics Improving ReSharper (more…)

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): Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples Pattern matching with generics (more…)

ReSharper 2017.1 and 2017.2 bring better support for C# 7.0 and C# 7.1, with a number of new inspections, quick-fixes and context actions. In this 6th part of our blog series, let's cover how ReSharper (and Rider) work with tuples and how they help with inferring tuple names (spec) in our code. Tuples have been around for a while, and keep evolving in both C# as well as in ReSharper's features that you know and love. In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples (more…)

As part of our blog series about ReSharper support for C# 7.0 and C# 7.1, let's talk about the default literal (spec) which was added to C# 7.1. It lets us initialize variables in our code regardless of these variables being value types or reference types. ReSharper adds inspections, quick-fixes and context actions around this new language feature. In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples (more…)

Many developers have been wishing for an async main method to be able to use async/await constructs in console-based applications. The good news is that C# 7.1 introduces support for this (spec)! ReSharper (and Rider) do so, too. Let's continue our blog series about ReSharper support for C# 7.0 and C# 7.1 with an episode that covers how ReSharper handles this new keyword. In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples (more…)

Today, we continue our blog series on ReSharper support for C# 7.0 and C# 7.1. The previous post touched on throw expressions (spec) and ReSharper's inspections, quick-fixes and context actions around these language features. Today, let's talk about expression-bodied methods, properties, local functions, constructors, destructors and event accessors. Or in short: expression-bodied “everything”! In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples (more…)

Let's continue our blog series about ReSharper support for C# 7.0 and C# 7.1! We've already blogged about how ReSharper (and Rider) handle out variables, today we'll look at throw expressions (spec) that are available in C# 7.0. Throw expressions allow us to throw exceptions from almost any expression, making our code more concise and readable. ReSharper adds inspections, quick-fixes and context actions around these language features. In this series: Out variables Throw expressions Expression-bodied "everything" Async main Default literal Tuples (more…)

Back in February, we wrote a State of the union about ReSharper C# 7 support, based on ReSharper 2016.3. Since then, a number of improvements have been made, both to C# as well as ReSharper (and Rider, which gets language support updates from ReSharper for free). ReSharper 2017.1 and 2017.2 both bring better support for C# 7.0 and C# 7.1, with a number of new inspections, quick-fixes and context actions. ReSharper understands the new syntax and constructs that C# 7.0 and C# 7.1 bring, and ties them into existing and new inspections, quick-fixes, navigation and refactorings: Binary liter

A new minor update for the ReSharper Ultimate family is available for download! ReSharper 2017.2.2 fixes the annoying code completion bug with duplicate parentheses (RSRP-466206) and addresses the remaining known issues when completing сode with Tab (RSRP-466421). It also improves the null checking quick-fix behavior (RSRP-464225) and correctly resolves .NET Standard 2.0 libraries in Visual Studio 2017 version 15.4 preview 4 (RSRP-466417). See all fixes in ReSharper 2017.2.2. ReSharper C++, dotCover, dotTrace, dotMemory, and dotPeek 2017.2.2 have been updated solely for compatibility rea

We've just released a bug-fix update to the ReSharper Ultimate product family: check out ReSharper Ultimate 2017.2.1. ReSharper 2017.2.1 fixes a few bugs in code completion, including a nasty bug in replace code completion with Tab (RSRP-466079, RSRP-466137); removes bogus red code in .NET Core applications that reference .NET Framework 4.7 or 4.6.2 assemblies (RSRP-466025); addresses a performance issue in navigation (RSRP-465988). Overall, ReSharper 2017.2.1 contains 50+ fixes. ReSharper C++ 2017.2.1 fixes problems related to formatting, including ClangFormat-based formatting,

Continuous testing (CT) is a super-helpful feature but only under one condition: sufficient performance. Unfortunately, in dotCover 2017.1 and earlier, CT could be a real pain on large and very large solutions (30+ projects). The problem lies in three performance-critical phases of CT (actually, this is true not only for CT but for all tests run under coverage), which are: Coverage process startup. Test execution (could be much slower than usual due to the additional statement-level instrumentation). Post-processing of coverage snapshots. In 2017.1