Support for raw memory dumps was probably the most voted and long-awaited dotMemory feature. Finally, it’s available in dotMemory 2017.2!
Indeed, there are cases when it’s impossible to profile a problematic application locally or remotely and take a regular dotMemory snapshot for analysis (e.g., because of security policies). Your last resort in such a case is typically a raw Windows memory dump. It can be taken with a number of tools, with the two most popular being Task Manager (comes with the operating system) and Process Explorer. Now, all you have to do is simply copy the dump to your computer and open it in dotMemory using the Import Dump command.
That’s it! The dump is converted to an ordinary dotMemory snapshot, so you can analyze it using all of the sophisticated dotMemory features like automatic inspections, retention path diagrams, etc.
A big part of our developer life is spent debugging code. Whether we like it or not, sometimes the only way to understand code is to run it and step through it step by step and see which values are being stored in variables, what is the result of a method call, and so on. This information comes in handy when exploring a codebase and when diagnosing and troubleshooting an issue in code.
In our previous posts about debugging, we’ve seen how we can run and debug a .NET project and set a breakpoint to inspect the call stack and variables that are currently in scope and how we can step through code. There are a few more tricks to know when it comes to debugging: exception breakpoints, conditional breakpoints, hit counters, and more! These advanced breakpoint types help reduce the time required to debug a certain application state or logic flow, letting us be more productive while debugging.
In this series:
Keyboard shortcuts described in this post are based on the Visual Studio keymap.
Let’s first look at the different breakpoint types supported in Rider!
Rider comes with a great debugger which allows attaching to a new or existing process and lets us place breakpoints to pause the application at a breakpoint and see what is going on while executing our code.
In this three-post series, we’ll look deeper at what we can do with Rider’s debugger and how it can help us debug our code as efficient as possible. In this series:
The table of contents will be updated as we progress. Keyboard shortcuts described in this post are based on the Visual Studio keymap.
In our previous post about debugging, we’ve seen how we can run and debug a .NET project and set a breakpoint to inspect the call stack and variables that are currently in scope and how we can step through code. All of this is possible thanks to the concept of run/debug configurations — for both normal applications as well as unit tests. A perfect topic for a blog post in our debugger series!
Please welcome the new .NET IDE’s first bugfix release: Rider 2017.1.1. You can either download the new build’s installer, or use Rider’s Help | Check for Updates menu to install a patch without the burden of downloading it all over again.
This bugfix improves debugging asynchronous code (RIDER-507) by actually allowing you to step into async functions or over async expressions, avoids overwriting applicationhost.config files (RIDER-7897), adds a bunch of fixes around Xamarin.Android and Unity (including ShaderLab syntax support), and more: the full list of fixes is 50+ issues long.
Note that this update does not address support for .NET Core 2.0: if you’re looking for that, rest assured that we expect to open Early Access Program for Rider 2017.2 next week, and .NET Core 2.0 will be supported from the very first build.
As developers, a good share of our time is spent debugging the software we are writing. The debugger is an invaluable tool not only to track down bugs, but also to help us understand what a piece of code is doing when it’s being executed.
Rider comes with an excellent debugger which allows attaching to a new or existing process and lets us place breakpoints to pause the application and inspect variables, the current call stack and so on. It supports all .NET frameworks, .NET Core, Mono, Xamarin, Unity, ASP.NET and ASP.NET Core, in standalone apps, web apps and unit tests.
A while back, we received a very interesting question: how can we run Entity Framework commands like adding migrations or updating the database, in Rider?
In Visual Studio, Entity Framework commands like
Update-Database are typically run in the Package Manager Console. This works great, but unfortunately, it isn’t very portable. These commands are PowerShell-based, and the Package Manager Console ties to several Visual Studio-specific objects making it impossible to host it elsewhere.
No need to worry, though! With Entity Framework Core, Microsoft provides command line tools that work cross-platform, which in this case means in any IDE on any supported operating system. Let’s see how to get started!
Today, a certain cross-platform .NET IDE hits its greatest milestone so far: Rider 2017.1 RTM is now available for download and purchase. If you’re an All Products Pack subscriber, the license covers Rider: just start using it right away.
What is JetBrains Rider
If you haven’t been following closely, here’s a quick summary of Rider.
Posted in How-To's