In my opinion, the best features are just a checkbox that enables powerful scenarios. Rider has features like this, and one of them is called incremental build. Behold!
Incremental build reduces the time needed to build a solution by only building projects that need updating. This helps us stay “in the zone”: the quicker we can rebuild a solution, the quicker we get compilation feedback, the quicker we can run unit tests, the sooner we can move on to working and improving our code.
We’ve seen the checkbox, now let’s look behind the curtains and find out how incremental build works!
Good news, everyone! A new Rider EAP build is now available for download!
As always, a fresh EAP means we’ve been fixing a number of bugs, improved existing features and added some new ones. Rider EAP 22 comes with:
- Xamarin Mac and iOS support lets us work on our code and run/debug our projects on emulators and real devices.
- Unit testing improvements with new toolbars, context actions and more.
- Our NuGet client now has a UI to manage NuGet package sources and shows the effective NuGet configuration in use.
- The debugger can now attach to compound configurations to debug two or more projects at the same time.
- Additional settings for code inspections were added.
- There’s now a Favorites tool window showing favorites, bookmarks and breakpoints.
- The productivity guide helps you become a Rider keyboard ninja!
Let’s take a look.
We’ve all been there. Investigating a bug, making some code changes, then finding that these changes don’t fix the bug. Rinse, repeat, and two hours later we realize that first attempt needed just a little tweak. How can we roll back to it if we did not commit it to Git or Mercurial? How can we roll back any change we made to the code base between source control commits? Undo only goes so far…
In JetBrains Rider, there’s a solution to that: Local History. It’s a real-time, local version control that keeps track of changes we make to our code base.
What is Local History?
When we’re “in the flow”, our project and source code constantly changes. We write, refactor and debug, and when we finish a task, code is committed to a version control system (VCS) like Git or Mercurial.
Unfortunately, commits to the VCS are just snapshots. If we’re lucky, changes in between commits are captured in the undo stack, but that disappears if we close the IDE and reopen it a later time. Undo also does not track external changes, made outside of the IDE. What’s even worse: don’t you hate it when you undo 20 times, then accidentally press the keyboard so you can’t redo anymore?
In the 2017.1 release, dotMemory introduced a console profiler. Now, using the dotMemory.exe tool, you can perform memory profiling from the command line. Why would you? The short answer would be to automate the process of gathering memory snapshots. There are lots of possible use cases:
- You want to speed up profiling routines, e.g. when you regularly profile the same application and do not want to start the dotMemory user interface each time.
- You need to profile your application on someone’s computer you don’t have access to (e.g., your client’s) but don’t want to bother him with dotMemory installation and detailed profiling instructions.
- Or maybe you want to include memory profiling into your continuous integration builds (though our dotMemory Unit framework could be much handier for this purpose).
Right after dotCover 2016.3 introduced a new way to highlight code coverage (markers in the gutter instead of colored backgrounds), we immediately got a flurry of “Bring it back!” comments. Indeed, there is a range of tasks where the “old-style” highlighting could be more useful, e.g. when you need to quickly evaluate uncovered parts of code.
Some technological limitations prevented us from keeping the colored-background highlighting along with the new markers in 2016.3. Fortunately, now all the limitations are left behind, and dotCover 2017.1 gets the old highlighting back. And it’s even better than before!
How much will Rider cost? Will it be a part of JetBrains All Products pack? We have faced these and related questions for quite a while, and it’s about time we make this information public.
Commercial and personal pricing
Here’s a list of USD prices in different licensing scenarios. These are first-year subscription prices. As usual, continuous subscription discounts are available: in the second year of uninterrupted Rider subscription, you get 20% off, and then 40% off in the third year onward.
||Commercial license /1st year
||Personal license /1st year
|Rider + ReSharper Ultimate
|All Products (includes Rider)
We’ve got a new bug-fix update for you: please welcome ReSharper Ultimate 2017.1.2.
- ReSharper adds 70+ fixes. This includes a set of unit test runner fixes: the runner now correctly runs the entire session instead of just running the current selection (RSRP-464189); test output is correctly displayed when running xUnit-based .NET Core tests in Visual Studio 2015 (RSRP-464330); and the runner learns to detect and run NUnit-based tests written in F#. Another substantial group of fixes addresses TypeScript support issues, such as false red code in imported code and other contexts, incorrect flow analysis, navigation in Angular 2 templates, and more.
- ReSharper C++ adds ~30 fixes covering Visual Studio’s Open Folder mode, code analysis and formatting.
- dotMemory and dotPeek bring a few fixes each, while dotCover and dotTrace are unchanged since the last release.
If you’re affected by the issues that this bug-fix release addresses, please download ReSharper Ultimate 2017.1.2.