Since the first Rider 2017.3 EAP build a few weeks back, we’ve made a number of incremental changes and improvements to project templates in Rider.
When creating a new solution or project, Rider gives us a number of templates by default:
Instead of grouping templates by language, Rider now groups project templates by framework. This reduces the length of the list of project templates and makes it easier to find what we are after. Rider comes with templates for .NET, .NET Core (if installed on our system) and Xamarin. For every framework, we can specify a series of options:
- Solution/project name and folder
- An option to create a Git or Mercurial repository
- The language to use — many templates support C#, VB.NET and/or F#
- The target framework that will be used — anything from .NET 3.5 to .NET 4.7,
netcoreapp2.0, … Note that for a framework to be available from this list, it has to be installed on our system.
- For Unity and Xamarin, several other options can be provided as well, for example the path to
UnityEngine.dll, the target platform (Android or iOS), the type of app (blank, Android Wear, …) Note that these options, too, depend on available frameworks on our system, such as the MonoAndroid versions installed.
If you are using any third-party library, either via NuGet or other sources, you probably have experienced the case where something does not work as expected. To figure out what’s going on we sometimes need to debug into that third-party library (or even just the .NET Framework itself). Making that work is usually another painful process in itself, setting up symbol servers and finding matching PDB files etc. Usually by the time you get this all working, you forgot what you wanted to debug in the first place.
The latest Rider 2017.3 EAP build solves all of the above, and makes stepping into third-party code a breeze! Here’s a simple ASP.NET application where we will use Step Into (F11) to debug the ASP.NET Core source code.
We’ve just stepped into ASP.NET Core’s
StaticFileExtensions, and even into .NET Core’s
Array class – debugging third-party code without any effort!
Rider 2017.3 EAP comes with support for Web.config and App.config transformations. These configuration transformations allow us to update certain settings in a Web.config or App.config file when packaging the application. For example, we may want to update the database connection string for a Release build, or update certain settings for a Debug build.
Using the context menu in Solution Explorer or in the editor, we can generate a configuration transform file for any of our solution’s configuration files. Optionally, we can nest the file under its parent configuration, too.
If you are using the latest ReSharper 2017.3 EAP build, you may have noticed a few changes in the Extract Method refactoring, which now comes with better support for C# 6 and C# 7. Support for local functions has been added, there’s now an option to return value tuple instead of
out parameters, and Extract Method now works in expression-bodied members. Let’s see!
Extract to local function
Starting with C# 7.0 we can make use of local functions – private methods that are nested in another member and that can only be called from their containing member. ReSharper 2017.3’s Extract Method refactoring (Ctrl+R, M) now supports extracting a bit of code into a full method, or into a local function:
A number of debugger improvements were made in recent Rider 2017.3 EAP builds. It’s now possible to drag-and-drop the execution point, several debugger actions are now part of Alt+Enter, Rider displays function return values in locals view, and for async calls we now expand the async call stack. And there’s also Smart Step-Into which we blogged about earlier.
Next to new features, there are the obvious bug fixes as well. There’s better support for NUnit and some mocking frameworks where Rider would not show proper type information (fixed “#Undecoded type” when debugging). The Rider debugger is now faster to attach to applications that make a lot of allocations.
In the latest Rider 2017.3 EAP builds, we have been hard at work improving the test runner experience. We’ve added a couple of new actions to re-run failed tests and repeat tests until failure. The Tests menu is now a separate menu entry, featuring all test runner actions. Filters are now visible based on context. Various UI improvements were made, making the test runner tool window nicer to work with.
Several bugs were fixed as well: when a filter is set (e.g. “show only failed tests”), unit test actions now use this filter. Some problems with NUnit on Linux and macOS were resolved as well.
Let’s look at a few of the unit test runner improvements!
New actions: Rerun Failed Tests / Repeat Tests Until Failure
When a test fails, we typically want to be able to quickly run it again after making a code change, to see if it passes. Both the toolbar as well as the Unit Testing quick list (Shift+Alt+U in Visual Studio keyboard scheme) now allow to Rerun Failed Tests (Ctrl+U, F).
In a recent talk I gave about Rider’s debugger, one of the things I mentioned is that while writing code, we spend a lot of time in the debugger to validate our logic. Because of this reality, debugging should be as painless as possible. With Rider 2017.3 EAP, we’re introducing Smart Step Into to make debugging lines with multiple statements easier.
While in the debugger, we may sometimes reach a line of code that performs several method calls. Let’s take this line of code as an example:
PrintPeople(FilterPeople(people, BuildPredicate(person => person.Company.Country, "CZ")));
If we’d want to step into
FilterPeople(), we’d first have to step through
BuildPredicate() before we get to the method we want to debug:
In the latest Rider 2017.3 EAP build, we have added a new C# Interactive tool window. It allows running C# statements without having to wait for compilation. This means we can get immediate feedback on what a given expression will return.
The C# Interactive tool window can be opened from the Tools | C# Interactive menu, or by pressing Alt+Enter in the editor and sending a code snippet to the interactive window: