Null checking is a very common task that ReSharper has always been helping to automate. Since the very first versions, ReSharper users had a whole bunch of context actions and quick-fixes at their disposal, such as Check parameter for null, Assert expression is not null and Check variable for null.
As we’re constantly improving the coding experience, we made a number of changes in previous releases: we extended the Check parameter for null action to check all parameters at once and also added an option to insert null checks when generating a constructor. ReSharper 2017.2 advances null checking even further. Let’s see!
Having code with XML documentation is great, as it allows generating nice API documentation and provides useful help while writing code:
ReSharper 2017.2 and Rider 2017.2 EAP give us more tooling to organize XML documentation across inheritance hierarchies.
When creating a class library that provides XML documentation, we can make use of the
<inheritdoc/> element to inherit documentation from a base class or an interface. Consider the following code:
/// <inheritdoc />
public class TenantAwareCustomerRepository
: ITenantAware, IRepository<Customer>
ReSharper and Rider continuously analyze the code we’re working on and help us detect errors and problems early on. They provide suggestions and hints as well, and for many of the 2300+ code inspections that are available, quick-fixes exist to automatically resolve detected issues. ReSharper 2017.2, as well as the Rider 2017.2 EAP, introduce several new code inspections and quick-fixes that help us write better code. Let’s have a look.
IEnumerable – Possible multiple enumeration
The Possible multiple enumeration of IEnumerable code inspection has been around for a while. It helps making sure we’re not enumerating a collection twice – something which could lead to excess work of a database or even to mutated state and strange results. ReSharper 2017.2 adds support for
ParallelQuery, next to the already existing inspection for
IEnumerable. Let’s look at what it does.
Consider the following code snippet:
IEnumerable<string> names = GetNamesFromDatabase();
foreach (var name in names)
Console.WriteLine("Name: " + name);
We’ve just opened the Rider 2017.2 Early Access Program (EAP) for you to download.
It comes with full support for .NET Core 2.0, adds MSTest, various NuGet improvements, a new debugger tool window for visualizing Parallel Stacks and marking of instances, new refactorings and more. And with ReSharper 2017.2 now released, we’ve updated the ReSharper version powering Rider, too. Which brings improved support for C# 7.0, initial support for C# 7.1, new code inspections, navigation improvements, and so on. Let’s look at a few highlights!
Support for raw memory dumps was probably the most voted and long-awaited dotMemory feature. Finally, it’s available in dotMemory 2017.2!
Indeed, there are cases when it’s impossible to profile a problematic application locally or remotely and take a regular dotMemory snapshot for analysis (e.g., because of security policies). Your last resort in such a case is typically a raw Windows memory dump. It can be taken with a number of tools, with the two most popular being Task Manager (comes with the operating system) and Process Explorer. Now, all you have to do is simply copy the dump to your computer and open it in dotMemory using the Import Dump command.
That’s it! The dump is converted to an ordinary dotMemory snapshot, so you can analyze it using all of the sophisticated dotMemory features like automatic inspections, retention path diagrams, etc.
A big part of our developer life is spent debugging code. Whether we like it or not, sometimes the only way to understand code is to run it and step through it step by step and see which values are being stored in variables, what is the result of a method call, and so on. This information comes in handy when exploring a codebase and when diagnosing and troubleshooting an issue in code.
In our previous posts about debugging, we’ve seen how we can run and debug a .NET project and set a breakpoint to inspect the call stack and variables that are currently in scope and how we can step through code. There are a few more tricks to know when it comes to debugging: exception breakpoints, conditional breakpoints, hit counters, and more! These advanced breakpoint types help reduce the time required to debug a certain application state or logic flow, letting us be more productive while debugging.
In this series:
Keyboard shortcuts described in this post are based on the Visual Studio keymap.
Let’s first look at the different breakpoint types supported in Rider!
Rider comes with a great debugger which allows attaching to a new or existing process and lets us place breakpoints to pause the application at a breakpoint and see what is going on while executing our code.
In this three-post series, we’ll look deeper at what we can do with Rider’s debugger and how it can help us debug our code as efficient as possible. In this series:
The table of contents will be updated as we progress. Keyboard shortcuts described in this post are based on the Visual Studio keymap.
In our previous post about debugging, we’ve seen how we can run and debug a .NET project and set a breakpoint to inspect the call stack and variables that are currently in scope and how we can step through code. All of this is possible thanks to the concept of run/debug configurations — for both normal applications as well as unit tests. A perfect topic for a blog post in our debugger series!