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).
But what with those typical TODO comments? Do they go into the issue tracker? Or should we simply annotate our code with short comments? Instead of starting a religious discussion, let’s look at how we can work with TODO’s in our code and IDE to describe these small, code-specific tasks.
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!
Back when we opened the public Rider Early Access Program (EAP), we announced Rider as a cross-platform .NET IDE. We started out with C# and VB.NET, but there are of course three major CLR languages, so that means… we have recently added initial F# support to Rider!
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.
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.
In this Rider EAP 21, we’ve fixed a number of bugs, bundled the TFS plugin to make working with TFS and VSTS easier, added detection of existing file indents for editing, added highlighting in XML doc comments, improved options pages for inspections and the NuGet client, and… added F# language support!
Rider EAP 20 fixes a number of bugs, improves .NET Core support, has better NuGet performance, supports Xamarin Android applications, comes with Node.js tooling from WebStorm (including SpyJS), can generate ResX files, executes T4 templates (needs Windows and Visual Studio SDK), adds support for scratch files, … Too much for one sentence, as you can see from the full list of fixes. We’ll highlight a few, read on!
You should definitely get this release if you have installed the latest Visual Studio 2017 update (April 6), and then when you tried to run your MSTest suite, you saw ReSharper telling you this:
Turns out that the latest Visual Studio update reverted a prior API change in a way that we didn’t expect, which kind of explains why ReSharper took the absolute latest Visual Studio build for an outdated one. The problem is now fixed, and you can run your MSTest suites again.
Apart from fixing the unit test runner issue, this update includes a small set of fixes in ReSharper C++.
dotMemory, dotCover, dotTrace and dotPeek have not received any bug fixes so far.
The recording of our recent webinar with Maarten Balliauw, Exploring .NET’s memory management, is now available:
We’ll take a trip down memory lane and look into how .NET memory management works. We’ll start off with the .NET Garbage Collector (GC) is really cool and look at how it helps providing our applications with virtually unlimited memory, so we can focus on writing code instead of manually freeing up memory. But how does .NET manage that memory? What are hidden allocations? Are strings evil? It still matters to understand when and where memory is allocated. In this talk, we’ll go over the base concepts of .NET memory management and explore how .NET helps us and how we can help .NET – making our apps better. Expect profiling using dotMemory, Intermediate Language (IL), and using ClrMD to mimic some inspections dotMemory provides.
All demos are available on GitHub and come with interactive walkthroughs, mostly. If you have dotMemory installed, you can investigate the results of each demo on your own!
Slides are on SlideShare, and a detailed blog series on the topic is available as well: