We’ve also added a preview panel for SVG files that helps visualize the syntax we are editing. Updates were made to detecting package.json files, helping Rider suggests installing or updating npm packages.
Not all of these will be covered in this post, however. Let’s start with the general web development updates in Rider 2017.3!
This post is part of a series: (we will update the table of contents as we progress)
- General web development updates in Rider 2017.3
Yesterday, we posted about a new feature in Rider 2017.3.1 – debugging third party code in Mono. This feature nicely rounds out Rider’s support for a specific Unity workflow – building and debugging external class libraries. Let’s take a look at how Rider can help here.
Unity will of course compile any C# scripts that are in the main Unity project, and it will generate the correct debugging information as part of the normal build process. Rider already has great support for debugging normal Unity C# scripts, and will automatically configure itself to attach the debugger to the Unity editor instance.
But Unity also supports the idea of an “external class library“. This is simply a .NET class library that Unity will automatically reference once it’s copied into one of Unity’s
Posted in How-To's
Tagged Rider, Unity
Back in December, we announced a really cool feature – the ability to seamlessly debug third party code in Rider. No need for a
.pdb file, just hit F11 and step in – Rider will decompile the code on-the-fly, and boom! you’re debugging, just like that. A fantastic feature, but only available for .NET Framework and .NET Core.
With the recent release of Rider 2017.3.1, we’ve updated this to also work with Mono, which brings this feature to all runtimes, on all platforms. That means Windows, Mac, Linux, .NET Framework, .NET Core, Mono and of course, Unity.
Rider 2017.3 was a bumper release and added a lot of new features, improvements and fixes. Let’s take a look at the Unity specific changes.
As a quick reminder, Rider is a cross platform C# IDE, for Windows, Mac and Linux, with built-in support for Unity. Rider happily opens, builds and tests Unity projects, with deep knowledge of the API and the way Unity uses your code, highlighting usages of Unity’s event functions and serialised fields and more.
First of all, we finally get a small but highly requested feature – Rider will now display external documentation for Unity symbols. Rider has displayed a summary tooltip on Unity types and event functions for a while now, but we’ve been missing the ability to view a web page with detailed help. Now, you can either click the icon from the Quick Documentation popup (Ctrl+Shift+F1 if using the Visual Studio keymap) or use the View External Documentation action (Shift+F1) directly to navigate to locally installed documentation, or to Unity’s hosted docs if not available locally.
Posted in How-To's
Tagged Rider, Unity
Baseline conditions: You have a server running a .NET web application. It appears the application has an issue: It doesn’t work as fast as expected, it consumes more and more memory over time, it has any other performance/memory issue of your choice, whatever. It doesn’t really matter what exact issue it has, the workflow is always the same:
- Profile the app in order to get performance/memory data.
- Analyse the data to determine the issue.
Though step 2 seems to be the most important here, communication with our users shows that you might easily get stuck in step 1. In most cases, installing a profiling tool like dotTrace or dotMemory to the server is not an option at all. Server environment may impose many restrictions: no GUI, security policies, etc. So, what options do you have? In this article, we’ll take a look at all possible ways of profiling a .NET application on a server using the dotTrace + dotMemory toolset.
TL;DR, here is a short summary:
||Not cons but features
- Easy to configure/use – you profile via the dotTrace/dotMemory GUI
- Snapshots are automatically uploaded to your local machine
- dotTrace/dotMemory remote agent must be run on the server
- Communication via network is required
- No network communication required
- Ability to create a number of predefined profiling configs and run them on demand
- The tools must be copied to the server
- Resulting snapshots must be manually copied from the server to the machine with dotTrace/dotMemory
|Memory dumps (only memory profiling)
- Nothing should be installed to the server
- No profiling overhead
- Memory dumps contain less data than dotMemory snapshots
Note: check our series about code formatting engine updates in ReSharper and Rider for more background.
ReSharper makes it possible to add (or remove) line breaks before and after specific language constructs. We can configure this in the ReSharper options, under Code Editing | Razor | Code Style. As with any code style settings, we can preview the effect of enabling/disabling the option from the preview pane:
Between the release of Rider 2017.3 and the start of 2018.1 EAP our team have worked diligently on cleaning things up, to provide you with a sleek and hassle-free experience with the IDE and today we’re happy to announce that we succeeded with the tidy new Rider 2017.3.1!
Among other things, in this update you will find:
— RIDER-12503 — Fixed unexpected project loading errors.
— RIDER-6714 — Fine-tuned syntax highlighting for XML documentation comments.
— RIDER-3491 — Shortcut for Move Caret to Matching Brace working as expected.
— RIDER-12420 — Shared run configurations are back in the solution-specific folder: ./idea/.idea.SolutionName/.idea.
— A lot of fixes in Code Completion including glitches with the autopopup and a set of improvements in the UI;
— 100+ more issues are also fixed, see the full list.
This bugfix release has a few noticeable enhancements as well:
— Rider debugger can now step into third-party code in Unity projects (and all other Mono-based projects too!).
— RIDER-12319 — Improved auto-detection of Unity Mono runtime.
— RIDER-8453 — Debugging on connected iOS devices in Xamarin.
— RIDER-9343 — Preview of Find Usages in the text editor.
Note: existing shared run configurations files created with 2017.3 still need to be manually put to the .idea/.idea.SolutionName/.idea/runConfigurations folder after you install 2017.3.1, but Rider will take care of them from there.
You can install this update either via Toolbox App, or as a patch for Rider 2017.3 (use Help | Check for Updates), or otherwise just get an installer from our website.
Though dotMemory Unit is not part of the ReSharper Ultimate bundle, in this release dotMemory Unit 3.0 is provided with ReSharper 2017.3. What’s in this release?
.NET Core 2.0 support
You’ve asked us to add support for .NET Core for quite a while. Now, with the more mature and stable .NET Core 2.0 release, this request became even more urgent. So, yes, dotMemory Unit 3.0 provides support for .NET Core 2.0 unit tests (currently, only on Windows).
The latest major release brought many important changes to the entire family of ReSharper Ultimate tools. In this post, let’s take a close look at what has changed in dotTrace 2017.3.
Support for async/await
The most important update in dotTrace 2017.3 is its support for asynchronous code. The details can be found in a separate article, so here we’ll only give an overview of the key idea.
You can now quickly find all “parts” of an asynchronous call in one place. dotTrace marks all
async call nodes in the Call Tree and groups the corresponding
await time and continuation code under those nodes.
Now let’s see what other important updates dotTrace 2017.3 offers.