With each Rider release, we do our best to bridge the gap between Rider and the ReSharper Ultimate bundle. The top in-demand feature has certainly been “Rider + dotCover” integration. So, without further ado, please welcome the latest Rider 2018.2 EAP build – the first Rider version ever that features unit test code coverage and support for continuous testing!
What exactly is dotCover able to do in Rider, and how is it going to be licensed? Read the answers below.
Continue reading
Last time in our series about C# 7.3 language features, we covered tuple equality. Today we will look at unmanaged, delegate and enum type constraints. The latest Early Access Preview (EAP) versions of ReSharper 2018.2 and Rider 2018.2 come with language support for C# 7.3, do give them a try!
This post is part of a series (we will update the table of contents as we progress):
Ever since C# 2.0, when generics were introduced, it has been possible to set type constraints on generic parameters. For example, we could specify that the type constraint should implement a specific interface, and perhaps also have a parameterless constructor:
|
1 2 3 4 5 |
public class Repository<T> where T : IEntity, new() { // ... } |
Generic type constraints can be added on class declarations, method declarations, and local functions. They allow us to constrain the types which can be used with the class or method we are creating.
Up until now, these constraints included reference type constraint (class), value type constraint (struct), interfaces or base class constraints, and whether a parameterless constructor should be present (new()). With C# 7.3, three new generic type constraints are introduced (proposal): unmanaged, System.Delegate and System.Enum.
(Fun fact: the CLR already supported these constraints, however the C# language prohibited using them. Jon Skeet has a blog post on making these constraints work in earlier C# versions.) Continue reading
Good news, everyone! Our latest Rider 2018.2 EAP (Early Access Preview) build comes with support for debugging ASP.NET Core apps in a local (Linux) Docker container. Being able to attach the debugger to a Docker container helps to validate our application locally in a Linux Docker container that should closely resemble production. Let’s see how this works!
Rider comes with Docker integration. We’ll have to configure Rider to connect to our local Docker daemon to enable it. Under Build, Execution, Deployment | Docker in the settings, we can add a new connection to Docker. Typically all we will need to configure is the engine API URL, which usually is tcp://localhost:2375.
Note that by default, Docker for Windows does not expose the daemon to Rider. This will have to be enabled in Docker’s settings:
Once configured, we can open the Docker tool window (View | Tool Windows | Docker) and inspect running containers, images, container logs and so on:
With that out of the way, let’s create a Docker run/debug configuration for our application. Continue reading
In February, the ASP.NET team announced the experimental project “Blazor” – a single-page web app framework built on .NET that runs in the browser with WebAssembly. Blazor is great news for all web developers and those who want to try something new. Basically, it allows us to create dynamic websites without writing any piece of JavaScript. Client-side logic can simply be implemented using C#, which is then compiled to use open web standards (WebAssembly).
Even though Blazor is declared experimental for now, we’ve added initial support for this promising framework in both ReSharper 2018.2 EAP and Rider 2018.2 EAP. For instance, code completion includes all the possible directives, like page (routing), inject (service injection) and function (component members):
Blazor allows to compose components from other components with simple HTML tags, which turns out to be a very flexible approach. For instance, when decorating a member with ParameterAttribute, we can set this member from any other component with a HTML attribute.
The ParameterAttribute is not yet supported, but for completeness, let’s see how this works:
This post is part of a 10-week series by Dino Esposito (@despos) around a common theme: code smells and code structure.
So far in this series about code smells, we made the point that keeping the language of the code close to the language of the business is crucial to reduce misunderstandings and to speed up development. Naming classes, methods and sparse values appropriately is part of the job. Today, let’s look at bringing the code even closer to the business language!
In this series: (we will update the table of contents as we progress)
A very common scenario in nearly all types of code is checking the value of a variable against a fixed range of values, mostly constants. In modern programming languages, the enum type is the artifact used to declare a list of named integer constants.
|
1 2 3 4 5 6 |
public enum RoomState { Unknown = 0, Available = 1, Occupied = 2 } |
While the value of any constant is an integer, an expression that evaluates to any of the constants is of a type that inherits from System.Enum. In the code snippet, it is RoomState. Enum values are typically assigned to variables or evaluated in conditional statements.
|
1 2 3 4 |
if (state == RoomState.Occupied) { Console.WriteLine("Room not available"); } |
Even when all you need to do is check a value against a constant, you never know what can happen next as the code base grows. Turning explicit constants into enum values is a good first step. Continue reading
The Early Access Preview (EAP) versions of ReSharper 2018.2 and Rider 2018.2 added support for C# 7.3. In this series, we are looking at these new language features in C# 7.3. Today, we will cover tuple equality.
This post is part of a series (we will update the table of contents as we progress):
More language evolution can be found in support for tuples. In C# 7.0, C# 7.1 and C# 7.2, the concept of value tuples and deconstructing tuples was introduced and expanded upon. In essence, some syntactic candy that provides a memory-friendly and developer-friendly way of working with tuples.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// C# 6 var tuple = new Tuple<string, bool>("Jason", false); if (tuple.Item2) { // ... } // C#7.0+ var tuple = (name: "Jason", isEmployee: false); if (tuple.isEmployee) { // ... } |
C# 7.3 builds on top of this foundation and adds tuple equality (spec). The C# language now lets us compare equality of two tuples more easily. Instead of having to compare all of the tuple’s items one by one, we can check equality (using == or !=) on the tuple itself. Here’s a code snippet to help grok this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
var tuple1 = (name: "Jason", isEmployee: false); var tuple2 = (name: "Jason", isEmployee: false); // Before C# 7.3 if (tuple1.name == tuple2.name && tuple1.isEmployee == tuple2.isEmployee) { // ... } // With C# 7.3 if (tuple1 == tuple2) { // ... } |
This is pretty nifty compiler magic and syntactic sugar. Imagine comparing a tuple with 5 items, or a tuple with two items that are nullable…
It’s worth mentioning that tuple equality also works with tuple expressions, which can improve readability on some cases. The following statements are equivalent in C# 7.3:
|
1 2 3 4 5 6 |
// C# 7.2 and earlier: if (employee.firstName == "John" && employee.surname == "Doe") { ... } // C# 7.3: if (employee == ("John", "Doe")) { ... } if (employee == (firstName: "John", surname: "Doe")) { ... } |
What with nullable types? Before C# 7.3, we’d have to check all tuple items for null before comparing equality. With C# 7.3, we can instead check equality at the tuple level:
|
1 2 3 4 5 6 7 |
var tuple1 = ((DateTime?)null, (DateTime?)null); var tuple2 = (DateTime.UtcNow, DateTime.UtcNow); if (tuple1 != tuple2) { // ... } |
Under the hood, the C# compiler uses lowering to convert this language feature to what we’d normally have to write, as we can see in the generated Intermediate Language (IL) code (ReSharper | Tools | IL Code). The compiler converted our a == b check into many IL instructions that check whether our tuple’s nullable DateTime instances have a value.
Do check the specification for tuple equality, there are some interesting cases in there as well, for example when using nested tuples – think (string name, (string employee, DateTime employmentDate)).
Tuple equality definitely makes code more readable and concise!
Download ReSharper 2018.2 EAP now! Or give Rider 2018.2 EAP a try. We’d love to hear your feedback!
Ever since C# 7.0 came about, the pace at which our beloved programming language evolves became more rapid. A few weeks back, C# 7.3 was officially released, adding several new features that can help us write cleaner, clearer and more concise code.
Let’s look at some of the new C# 7.3 language features and how the Early Access Preview (EAP) versions of ReSharper 2018.2 and Rider 2018.2 support it. In this post, we will cover declaration expressions in initializers and queries.
This post is part of a series (we will update the table of contents as we progress):
C# 7.0 already permitted the use of expressions containing expression variables. An example would be using an out variable declaration (more details in our previous series):
|
1 2 3 |
if (int.TryParse("42", out int number)) { // ... work with number ... } |
This pattern was not available for every expression. With C# 7.3, declaration expressions can now be used in field initializers, property initializers, constructor initializers and query clauses (spec). Here’s an example where we initialize a field with an out var declaration expression:
|
1 2 3 4 5 6 |
public class DeclarationExpressionsExample { public bool inputIsPositiveNumber = int.TryParse(ReadString(), out var input) && input > 0; public static string ReadString() => Console.ReadLine(); } |
It’s worth mentioning that the scope of these variables (in the above example, input) is limited to the containing initializer. So if we have multiple of these expressions in one type, they will not conflict:
|
1 2 3 4 5 6 7 8 9 10 11 |
public class DeclarationExpressionsExample { public bool inputIsPositiveNumber = int.TryParse(ReadString(), out var input) && input > 0; public bool ObjectIsPositiveNumber { get; } = ReadObject() is string str && int.TryParse(str, out var input) && input > 0; public static string ReadString() => Console.ReadLine(); public static object ReadObject() => Console.ReadLine(); } |
(Note we snuck in another example of declaration expressions here, this time in a property initializer.)
ReSharper and Rider recognize this new C# 7.3 syntax, and are aware of their scope, which can depend on the construct where the declaration expression is used. For example when using a declaration expression in a constructor, ReShaper and Rider are aware that the declared variable is available within the full scope of that constructor:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class DeclarationExpressionsExample { private readonly bool WrapsPostiveNumber; public readonly int Number; private DeclarationExpressionsExample(bool wrapsPostiveNumber) { WrapsPostiveNumber = wrapsPostiveNumber; } public DeclarationExpressionsExample(string str) : this(int.TryParse(str, out var input) && input > 0) { // "input" is available in the scope of the constructor Number = input; } } |
Similarly in queries, the declared variable would be available within the scope of its containing clause, but not outside of it. So in the following example, we can make use of the number variable within our where, but not in our select.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// Works: return from str in enumerable where int.TryParse(str, out var number) && number > 0 select str; // Doesn't work: return from str in enumerable where int.TryParse(str, out var number) && number > 0 select new { A = str, B = number // "number" is not available in this scope }; |
ReSharper and Rider will provide similar code analysis and refactoring functionality as with declaration expressions in other expressions, as declaration expressions in initializers and queries are mostly extending already existing language features.
So for example, when doing a type check and cast combination, ReSharper and Rider will suggest to use pattern matching instead:
Using declaration expressions in initializers and queries will definitely provide cleaner code in these additional cases.
Download ReSharper 2018.2 EAP now! Or give Rider 2018.2 EAP a try. We’d love to hear your feedback!
Our latest Rider 2018.2 EAP (Early Access Preview) introduces a series of improvements to the debugger. Generic types, async function names, constructors, static methods and other type information in .NET call stacks are now displayed in a more meaningful way. We added thread-specific breakpoints for multi-threaded applications. Mono and Unity developers will be happy with the ability to inspect unsafe pointers. It’s now possible to change debugger settings while running. And more! Let’s have a look.
While debugging, we can inspect what our code is doing. When execution is paused, we can inspect variables, and see the current execution stack. Traditionally, this stack displayed type information as seen by the .NET runtime. For example, when debugging async methods, we would see the underlying state machine in our call stack, rather than the name of our async method:
No longer! Rider 2018.2 comes with improvements in presenting generic types, async function names, constructors, static methods and other type information in .NET call stacks. Instead of that MoveNext() method, we can now see the name of our async method:
Rider now displays call stacks that make use of modern C# features in an understandable way. Continue reading
The latest builds of ReSharper 2018.2 EAP and Rider 2018.2 EAP come with the ReSpeller extension, providing spell-checking functionality out of the box. Just like with code analysis, ReSpeller scans for spelling mistakes and typos in identifiers, comments, string literals and more, and provides quick-fixes to resolve the problem. Let’s have a look!
ReSpeller will look for spelling mistakes in identifiers, comments, and string literals. When it detects a potential spelling mistake or a typo, it will let us know in the same way ReSharper and Rider display other code suggestions:
We can then invoke the Alt+Enter menu where ReSpeller gives us several options to fix our mistake: we can either fix our typo or add this word to ReSpeller’s dictionary.
This post is part of a 10-week series by Dino Esposito (@despos) around a common theme: code smells and code structure.
Welcome back to our series about code smells! Today, we’ll look at overriding the ToString method, and make use of extension methods.
In this series: (we will update the table of contents as we progress)
In the .NET Framework, getting the text description of a class instance is as easy as calling the ToString method – one of the foundational methods of the root System.Object class. In its default implementation, the method simply returns the type name.
A plain override can instruct the class to return a more meaningful string! Continue reading
