Good news, everyone! GREAT news everyone! The Rider Release Candidate (RC) build is now available for download!
With this Release Candidate, we’re taking a big step towards Rider’s first release, we’re almost there. The RC is a release configuration build, which means you shouldn’t be seeing any exception collection/reporting activity in the status bar (although exceptions, if any, will still be logged for support purposes.)
In terms of functionality, we’ve improved performance, refactorings and Unity support, enabled more WebStorm features, worked on the debugger, added VB.NET typing assists, implemented NuGet private feed authentication and fixed several bugs. Let’s have a look!
We have a new Rider EAP build for you today. Highlights of this build include performance and memory consumption fixes, Unity support improvements, and F# Interactive, accompanied by a few dozens of bug fixes.
There’s a new Rider EAP build available for download, and it’s full of changes, large and small, including Code Cleanup, new project and solution settings, VB.NET project templates, F# unit testing, an updated console, per-framework Solution Wide Analysis results, as well as hundreds of bug fixes.
However, one thing clearly stands out:
.NET Core debugger is back on Mac and Linux
Back in February, we were forced to temporarily disable .NET Core debugging due to a licensing issue (for a recap, here’s what happened). Restoring the functionality on Windows was fairly straightforward (it only took us one week); Mac and Linux, not so much.
Finally, following a few months of reading, writing and debugging code, scratching heads, testing and fixing, we’re ready to roll it out: you can debug .NET Core on OS X and Linux again.
Posted in How-To's
Tagged .NET Core, ASP.NET, C#, code analysis and quick-fixes, code style, debugger, EAP, F#, Rider, unit testing, VB.NET
Are you having issues installing ReSharper in the last few days? Does the ReSharper installer complain that it doesn’t find any zones exactly matching 15.something?
If this is what you’re seeing, then get ReSharper Ultimate 2017.1.3. Looks like that the latest Visual Studio 2017 Preview (15.3) has changed its internal versioning, which affected stable Visual Studio versions installed on the same machine, which ReSharper had no way of being aware of. With this ReSharper update, the problem should be gone.
Other than a fix to the installer issues, there’s essentially nothing else in this update: if you have not installed and are not planning to install a Visual Studio 2017 Preview build, then you can safely skip this ReSharper update.
Note to ReSharper 2017.2 EAP users: the latest ReSharper Ultimate 2017.2 EAP build released last week already contains the necessary fixes.
Last week, we announced the ReSharper Ultimate 2017.2 EAP (Early Access Program) is now available. If you downloaded it already, you may have discovered some of the new features and enhancements made in ReSharper and ReSharper C++.
If not, no worries! In this post, we’ll look at what the first ReSharper Ultimate 2017.2 EAP build brings to the table.
ReSharper Ultimate 2017.2 Early Access Program is now underway: you are welcome to download and install the latest builds of ReSharper, ReSharper C++, dotCover, dotTrace, dotMemory, dotPeek, as well as various command-line packages that we provide.
So far, version 2017.2 mostly incorporates changes to ReSharper and ReSharper C++. For example, the new ReSharper starts to support C# 7.1, TypeScript 2.3 and Angular 4, has its code completion optimized, offers various navigation improvements, and adds more language injections. ReSharper C++ 2017.2 introduces support for extended friend declarations from C++11, selection statements with initializer from C++17, and more language features.
Please download ReSharper Ultimate 2017.2 EAP, read a quick summary of changes, and expect us to elaborate on the improvements in coming weeks.
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).