JetBrains Rider Essentials

A list of tips & tricks for a new Rider user

The first thing to do is to download and install ToolBox to manage all the JetBrains related tools & IDE’s

Changing IDE default directories used for config, plugins, and caches storage

Common cases when you may need to change the default locations of the IDE file

• user profile drive runs out of space
• disk is slow and you want to use faster HDD or SSD for caches

Locations can be changed by editing idea.properties file. The easiest way is to use Help | Edit Custom Properties… menu action. It will create a copy of this file in the appropriate location so that the original file in the IDE bin subdirectory remains unmodified and doesn’t cause conflicts during the patch updates.

Follow the comments in C:\Users\<user>\AppData\Roaming\JetBrains\Rider{current Version}\idea.properties file to change the defaults, make sure to uncomment the lines defining these properties:

• idea.config.path
• idea.system.path
• idea.plugins.path
• idea.log.path

Example 
idea.config.path=c:/work/idea/caches/trunk-config
idea.system.path=c:/work/idea/caches/trunk-system
idea.plugins.path=c:/work/idea/caches/trunk-plugins

Find Actions and Options

JetBrains Rider helps you quickly find and apply any of its IDE’s actions, without digging through the menu.

Find and execute actions or find and change preferences
Do one of the following:
Press Ctrl+Shift+A or Ctrl+T (Based on the keybindings)
While the focus is in the editor, press Alt+Enter.
In the main menu, choose Help | Find Action…
Start typing the name of an action or setting or try any related words. For example, you can type property to find actions related to type members

Debug External Code

JetBrains Rider makes debugging external-library code simple, thanks to its integrated decompiler which decompiles external code on the fly and injects it into the debugger.

To enable or disable external code debugging, select/clear Enable external source debug on the Build, Execution, Deployment | Debugger page of JetBrains Rider settings.

Add Git Bash Terminal

The terminal emulator inside Rider runs with your default system shell, but it supports many other shells, such as Windows PowerShell, Command Prompt cmd.exe, sh, bash, zsh, csh, and so on.

For information about changing the shell, see Configure the terminal emulator.

Open: View | Tool Windows | Terminal or Ctrl+Alt+1

Configure: Settings | Tools | Terminal | Shell Path — Add the Git Bash.exe path

Manage change Lists

A change list is a set of local changes that have not yet been committed to a VCS repository. With change lists, you can group changes related to different tasks and commit these sets of changes independently. See Commit changes locally for details.

Change lists are displayed in the Commit window. Initially, there is a single Default Change list It is displayed in bold to show its active status, which means that all recent changes are automatically placed in this change list.

There is also an Un versioned Files change list that groups newly created files that haven’t been added to your VCS yet.

Shelve and Un shelve changes

Shelving is temporarily storing pending changes you have not committed yet similar to Git stash but works only inside Rider. This is useful, for example, if you need to switch to another task, and you want to set your changes aside to work on them later.

With JetBrains Rider, you can shelve both separate files and entire change lists.

Local History

Local History helps you constantly track all changes made to a project independently of version control.

Unlike version control systems, which only keep track of the differences made between commits, Local History offers much more. It automatically records your project’s state as you edit code, run tests, deploy applications, and so on, and maintains revisions for all meaningful changes made both from the IDE and externally.

Right Click Context menu of a file, folder, or any code element | Local History | Show History / Show History for Selection

For more info on How to Restore deleted files & Add labels to specific states in Local History refer Local History.

Performance Profiling of .NET Code using DotTrace Inside Rider

Step 1. Configuring a profiling session

• On the toolbar, in the list of profiling configurations, select Edit Configurations…
• In the opened Profiling Configurations window, click + to add a new profiling configuration (Sampling, Tracing, Line-by-line, Timeline).

For more info on choosing the profiling Types refer here.

Step 2. Running the session or attaching the running process and getting snapshots

• On the toolbar, select the run configuration you want to profile.
• Either select Run | Profile ‘run_config_name’ Using ‘profiling_config_name’ or click the corresponding button on the toolbar.

• Once the profiling is started, you will see the Performance Profiler tool window opened on the Profiling tab with the profiling controller inside.
• If you disabled Collect profiling data from start in the profiling configuration, click Start Recording to start recording profiling data. Now all you need is reproduce the performance issue you are looking for or, if you just evaluate the overall app performance, go through the desired usage scenarios in your application.
• Click Get Snapshot. The collected snapshot will be added to the list of snapshots inside the Performance Profiler window. To start collecting profiling data again, click Start Recording one more time.
• After you collect a snapshot(s), you can finish the profiling session. Normally, you do it either by closing the profiled application or by detaching the profiler via the Detach button (Kill forcibly terminates the profiled app and the session, so, use it only in emergency cases).

Step 3. Analyzing collected snapshots

Analyze the collected data using one of the views:

• Call Tree: a “classic” call tree that shows you all method calls in all threads. Each top-level node represents a top-level function which was executed by a certain thread. Use this view to quickly get down to actual application activity. Learn more
• Top Methods: the best place to start when analyzing application performance. It is a simple plain list of methods with the highest execution time. Note that you can reduce the system functions “noise” by excluding them from the list using the toggle: if enabled, method’s execution time is calculated as a sum of method’s own time and the time of all child system methods (down to the next user method in the stack).

Once the suspicious method is found, press F4 or select Jump to Source from the context menu. Rider will navigate you right to the method’s source code.

For more details on how to analyze performance snapshots, refer to Analyze Profiling Results.