How to instantly profile any method in your code with ReSharper and dotTrace

As you may already know, starting with ReSharper 9 all our .NET products share a common platform (including ReSharper, dotCover, dotTrace, dotMemory, and dotPeek). This allowed us to create the ReSharper Ultimate bundle which includes the entire .NET product lineup.

In our recent posts about ReSharper Ultimate, we promised that thanks to the shared platform, dotTrace (as well as other .NET tools) would become more integrated with ReSharper.

So, what does the new ReSharper 9.2 release bring us and how does dotTrace benefit from it?

Run configurations in ReSharper 9.2

Along with other important features and changes, ReSharper 9.2 introduces run configurations. You’ve probably already read about them in our recent blog post. In a nutshell, they give you an ability to pre-define run parameters for your startup project, an arbitrary executable, or even any static method. Then you can quickly run or debug a particular configuration without the need to set up parameters.

What does this mean for dotTrace 6.2?

So, how does dotTrace benefit from the ReSharper’s ‘run configurations’? As both products share the same platform, dotTrace is able to profile any run configuration you create.

Important! No ReSharper installation is required for this feature to work in dotTrace 6.2. Nevertheless, without ReSharper, the only way to create and profile run configurations is the Performance Snapshot Browser window. This seriously reduces the usability of the feature. That’s why having ReSharper installed is strongly recommended.

Profiling run configurations for projects and executables is not so exciting, though it does provide some sensible benefits. The main one is that you can create a number of configurations once and then quickly start profiling any configuration.

Quick profiling of a run configuration

A much more interesting ability is profiling run configurations of specific static methods, and that’s what we’re going to talk about.

Profiling specific methods

With dotTrace 6.2, you can instantly profile any static method in your code. As simple as that! You don’t even need to create a special run configuration for this. Simply place the caret on the method, press Alt+Enter, and select Debug | Profile ([profiling_type])* in the action list.

* The default profiling type is specified in the Performance Snapshot Browser window available via ReSharper | Profile | Show Performance Snapshots.

Profiling of a static method

Now, just imagine what this feature can do. You can profile any part of your code in place, right after you’ve written it! No need to build your solution, run the profiler, perform a usage scenario that runs your new code, etc.

For example, we’ve just written a feature in our application called Goo. There is a Goo class that has the Goo() method performing some complex calculations on an int array.

Wouldn’t you like to find out instantly if this algorithm is effective? No problem, we simply add a static method that creates an instance of the Goo class and runs the Goo() method.

Almost there. Now we just use Alt+Enter on the method and select Debug | Profile ([profiling_type])….

Static method created for profiling

In the Run Configuration Properties window that opens, among other run configuration parameters we’ll be asked whether we want to just run profiling of this configuration or run profiling and save the configuration (in case we’d like to use it again later):

Run configuration properties

After we click Execute, dotTrace will run our RunGoo() method under a special JetLauncher process that will be profiled. Right after the method finishes working, dotTrace automatically collects a snapshot and opens it in a viewer: Timeline Viewer for timeline profiling, and Performance Viewer for all other profiling types.

Call stack in TV

There we go! We’ve got all the details about how much time our feature requires, including time values for the entire call subtree.

Note that if you use the Timeline profiling type, in addition to call time values you also get a lot of other data on your code to answer questions such as:

  • How much memory does your code allocate?
    Timeline memory allocation
  • How much time does the File I/O, JIT, SQL queries processing (if there were any), etc. take?
    Timeline interval filters
  • Were there any blocking garbage collections?
    Timeline blocking GC

If after analyzing the snapshot we open the Performance Snapshot Browser window (by going to ReSharper | Profile | Show Performance Snapshots), we’ll see the collected snapshot. We can either delete it or keep for future analysis.

Snapshot browser in VS

Easy, isn’t it? The suggested workflow looks similar to performance testing but it’s much easier: You don’t even have to add a separate test project to your solution or reference a unit testing framework. Simply create a static method right near the code that you want to check, and profile it in a couple of clicks when needed.

We hope you find this new feature useful. Do try it on your own by installing the latest dotTrace 6.2 or the entire ReSharper Ultimate toolset.

Posted in dotTrace Tips&Tricks, How-To's | Tagged , , , , | 4 Comments

ReSharper 10 EAP 3: Continuous Testing and ReSharper Build

ReSharper 10 Early Access Program goes on and today we’ve prepared a new build highlighted with major features in ReSharper and dotCover.


ReSharper Build

ReSharper Build is a brand new ReSharper 10 feature that originated from an internal tool that the team used to build ReSharper itself. ReSharper Build is an out-of-process incremental build tool that can take advantage of multiple processes, visualizes different kinds of project build status, and is optimized for large solutions with lots of dependencies.
ReSharper Build & Run tool window

At this point ReSharper Build supports most .NET project types available in Visual Studio, except for Web Sites and ASP.NET 5 applications. Unmanaged C++ can be built using ReSharper although not all features will be available in this case. If you choose to use ReSharper Build and the solution you’re going to build is not supported (or contains projects that are not supported), ReSharper Build will automatically switch to Visual Studio’s native build process.

Note that ReSharper Build is off by default. In order to switch to ReSharper Build instead of Visual Studio’s native build process, go to ReSharper | Options | Tools | ReSharper Build and select ReSharper Build.

ReSharper build switch to VS Build

We’ll follow up shortly with a separate detailed blog post on the ins and outs of ReSharper Build.

Code style and configuring inspections

ReSharper 10 EAP 3 comes with a set of changes aimed to simplify configuration of and complying with code style settings.

For example, inspection severity can now be configured right from the Alt+Enter menu, without using a modal window:
Configuring inspection severity from bulb menu in ReSharper 10

Find similar issues modal window is now used only for searching in a custom scope. All default scopes, such as solution, project and file, can be applied right from the ALt+Enter menu.

A part of code style settings can now also be configured without leaving the Alt+Enter menu:
Configuring code style from the bulb menu in ReSharper 10

Additionally, there are new code inspections with quick-fixes that detect explicit or implicit access modifiers for types and type members, let you use a pre-configured order of modifiers, and help you join or separate attributes in a section.
A quick-fix to improve the order of modifiers

Other changes

On another note, there are also changes related to TypeScript and JavaScript, such as improved TSX support (though still not final) and JSX support in plain .js files.

If you’re interested, here’s a detailed list of fixes that made it into ReSharper 10 EAP 3.


Continuous Testing

If there’s anything that this EAP build proves, it’s that you should never, ever lose hope. dotCover boosts its version to 4.0 and reveals a preview of Continuous Testing.
Starting a Continuous Testing session
Following an initial code coverage analysis of your solution, dotCover then tracks your code changes, figures out which tests are affected by them, and then it can re-run the affected tests as soon as you hit Save, or use a different strategy of reacting to code changes.
Continuous Testing Session tool window
We’ll write more about the way Continuous Testing is implemented very soon. We know there’s quite a lot of ways to improve the feature but if you’re ready to try it out, please let us know of any issues you’ve had on your first approach.

ReSharper C++

In addition to a set of fixes, the new ReSharper C++ EAP build incorporates the following changes:

  • Usage-aware Go to declaration is now supported in a way similar to the mainline ReSharper.
  • New code inspections are available to detect uninitialized base class, accompanied by a quick-fix to initialize a member/base class.
  • Evaluation of compile-time expressions of floating point types is added.

What’s next?

First of all, make sure you didn’t forget to actually download the new EAP build.

We are expecting more EAP builds coming shortly so stay tuned for further updates.

Posted in How-To's, News and Events | Tagged , , , , , | 12 Comments

Run Configurations: debug any static method in Visual Studio, and more

Sometimes when you’re writing code, you want to verify an assumption quickly, check how your API works, or simply prototype and execute a small part of your code.

What common options are available to us?

  1. Create a separate small project, put the code to verify into its Main() method, and add all the necessary dependencies.
  2. Hook the code to verify to a random button and start the debugger (and hopefully remember to remove the code afterwards).
  3. Write a temporary unit test and execute it with the Unit Test Runner.

Well, with ReSharper 9.2’s new run configurations there’s now a better way.

With the caret on a static method without parameters, press Alt+Enter to see a context action called Debug:

ReSharper's Debug context action

Calling this action triggers debugging, with this very static method used as an entry point. In other words, without breaking your coding flow, you can write a public static void SomeTestMethod() right where you’re coding and quickly launch the debugger.

Under the hood, this context action is based on a new feature, run configurations. The feature grabs information required to execute from the current project, creates an implicit run configuration, and actually executes it.

The Debug menu item can be expanded to reveal the entire set of available actions: Debug, Run and Profile (available if dotTrace is installed), each in two varieties: with or without building. Each of the expanded actions opens a dialog box where you can refine configuration parameters as necessary, and execute the configuration with or without saving it for the future.

Run or debug any static method without parameters

When you choose to save and execute, your settings are persisted so that you can reuse them later. There are three ways to access a saved configuration:

    • A pinned gutter icon next to a static method
      Gutter icon for a saved run configuration
    • The Run Configurations pop-up that is available by selecting ReSharper | Tools | Run Configurations or with a shortcut (Ctrl+Shift+Alt+R in both Visual Studio and IntelliJ keymaps)
      Run Configurations popup
    • If you have dotTrace integrated into Visual Studio, you can also access run configurations via its Performance Snapshots Browser (ReSharper | Profile | Show Performance Snapshots).
      Performance Snapshots Browser

    ReSharper 9.2 provides three kinds of run configurations:

    • Executable: Allows running any executable file.
    • Static Method: As suggested above, this lets you run any static method that doesn’t have parameters.
    • Project: Allows executing a Visual Studio project (which in essence emulates setting a project as startup and launching it immediately).

    You can add any of these configurations via the Add… submenu in the Run Configurations pop-up.

    In addition, there is a new item in the project context menu, Create Run Configuration, which creates a new project run configuration.

    The Run Configurations pop-up provides quick keyboard access to configurations. It allows you to execute any run configuration in any supported execution mode. Each configuration’s submenu provides a set of Configure commands.

    A run confgiration's Configure menu

    One of these commands, Select, deserves a notable mention. Select assigns the current configuration to launch when you invoke Visual Studio’s own Start (F5) and Start Without Debugging (Ctrl+F5) commands. In addition, two Alt-modified shortcuts are added which affect whether or not a solution is built before launch:

    • Alt+F5: Debug without building
    • Ctrl+Alt+F5: Execute a configuration without debugging and building

    A setting called Don’t build by default that concludes the Run Configurations pop-up serves to swap the default and Alt-modified actions. For example, it makes F5 invoke debugging without building.

    Other Configure options include:

    • Edit, Duplicate and Delete: Fairly self-descriptive.
    • Share/Unshare: Saves a run configuration to shared solution settings (instead of the default personal solution settings), which enables sharing the run configuration among all developers working on the current solution.
Posted in How-To's | Tagged , , | 6 Comments

Performance Profiling in Continuous Integration: dotTrace and TeamCity

Performance testing is growing more and more popular as one of the most effective methods for preventing application performance regression.

Usually, by performance testing developers mean web application load testing, stress and spike testing, i.e. all types of tests that measure system behavior under particular loads. Nevertheless, performance testing is not only about loads. Tracking the execution time of critical application features (like rendering a scene in a game application, or filtering a large amount of data in an enterprise application) is also an important aspect of performance testing.

When tracking the execution time of critical features, a typical CI workflow looks as follows:

  1. Write an integration test that runs performance-critical functionality in your application.
  2. Configure your CI system to run this test during a build.
  3. Configure the CI system to check test execution time. If it exceeds some threshold (expected performance), fail the build.

Although such an approach looks easy to implement, it has some drawbacks. First, depending on the CI system you use, step 3 may be quite tricky. You need to add some custom failure condition for the duration of the specific test, and your CI server may not support this out of the box. Second and more important, when such a build fails because of your test, you don’t have a clue as to why this happened.

To find the exact methods that have become slower due to regression, you need either to thoroughly examine your code or (and this is much more effective) profile the problematic test in a performance profiler. So why not do this right on the CI server? Why not run the test under a profiler, and if there’s a slowdown, fail the build and get a performance snapshot?

We tried to solve this problem using two of our products: dotTrace performance profiler and TeamCity CI server. The brainchild of our efforts is the dotTrace Profiler plugin for TeamCity. With this plugin, the performance testing workflow becomes even simpler:

  1. Write integration tests.
  2. Add the plugin runner as a build step to your build configuration.
    In the plugin parameters, specify the methods (tests themselves or the methods they run) whose performance you want to measure. Specify the corresponding performance thresholds: absolute own time or total (own + call subtree) time, in ms. It’s also possible to compare measured values against values from previous successful builds.

Now, if at least one method exceeds its threshold, the plugin will fail the build and save the collected performance snapshot to build artifacts.

Here’s how the workflow looks in one picture:

Plugin workflow

For this plugin to run, only the free dotTrace console profiling tool is required. You will only need the full version of dotTrace if you want to analyze the collected performance snapshot.

Now let’s take a closer look at how to use the plugin.

1. Install the Plugin and dotTrace Console Profiler

  1. On your TeamCity server, copy to the plugins directory located in your TeamCity data directory.
  2. Restart the TeamCity Server service.
  3. As the dotTrace console profiling tool is required for the plugin, download and unzip the console profiler to any directory on a TeamCity build agent.

IMPORTANT! Unit test runner must also be installed on the same agent. In our example, we will use NUnit.

2. Write an Integration Test

Let’s suppose we have an application with a killer feature called Foo. For example, we have a Foo class with the Foo() method which, in turn, uses a Goo class. It creates a Goo instance and runs its Goo() method, which also runs some methods. We assume the execution time of the Foo feature is crucial for user experience. So we add a performance NUnit test that runs the feature:

3. Create Profiling Configuration

The next step is to tell the dotTrace console tool what application it has to profile. This is done via an XML configuration file. If you have a standalone dotTrace installation, you can simplify file creation by using the Configuration2Xml tool which is located in the dotTrace installation directory. Otherwise create the file manually by using the format described below.

  • To profile tests, we must profile the test runner that runs them (NUnit in our case). That is a standalone application, that’s why the main Argument tag has the type="StandaloneArgument" attribute.
  • The Filename tag specifies the path to the NUnit console runner installed on the agent.
  • In Arguments we specify the path to the DLL with integration tests. As you don’t know in advance where TeamCity will put the built DLL, you cannot specify the full absolute path to it. Instead, you can use the %CHECKOUTDIR% placeholder. During the build, the plugin will replace the placeholder with the checkout directory path. Therefore, all you need is to specify the path which is relative to the checkout directory. In our example it will be
  • Working directory specifies the path to the NUnit bin directory.
  • NUnit creates a separate runner process to run tests. To profile only the runner process, we must exclude the main NUnit process from profiling as follows:
    • Set the ProfileChildProcesses to true.
    • In the Scope | ProcessFilters | Item | ProcessNameFilter, specify nunit-console*.
    • In the Scope | ProcessFilters | Item | Type , specify Deny.
  • In MeasureType, specify the type of profiling you want to use. This should always be the Sampling type as it gives the most realistic time values. Note that the plugin does not support Timeline profiling.
  • Leave other options as shown above and save the file. In our example, we will name it myconfig.xml and store it in the console profiler directory.

4. Create Build Configuration

IMPORTANT! To help ensure consistency of profiling results, you should assign the build configuration that uses the plugin to a specific build agent (hardware agent is strongly recommended). For further instructions please refer to TeamCity documentation.

The next step is to create the build configuration dedicated for performance testing in TeamCity. For example, we already have My Project. Let’s add to that project a configuration consisting of two steps: building the application and running performance tests. To save time, let’s proceed right to configuring the second build step.

  1. In build configuration settings, go to Build Steps and click Add build step.
    Creating build configuration
  2. In Runner type, select dotTrace Profiler.
  3. Set the following plugin options and then click Save:
    • Console profiler path – the path to the directory storing dotTrace console profiler. In our example, it’s C:\Console Profiler
    • Profiling config file path – the path to the XML configuration file we created on the previous step. In our example, it’s C:\Console Profiler\myconfig.xml
    • Temp directory path – the path for storing a temporary performance snapshot. Note that this snapshot is auto-deleted each time the build is run.
    • Publish performance snapshot to artifacts – sets the condition for publishing a snapshot to the artifacts directory: Always, Never, or On exceeding thresholds. While the latter is the most reasonable choice, keep in mind that, depending on application complexity, the snapshot may take up hundreds of MB of disk space. We recommend updating your artifact cleanup policy so that after some time TeamCity would delete from the artifacts folders.
    • Threshold values – specify the list of methods whose performance you want to check. The pattern is Namespace.Class.Method TotalTime OwnTime, where
      • TotalTime is the method’s execution time, including its own time and the time of the method’s call subtree, in ms;
      • OwnTime is the method’s own execution time, in ms.

      (Setting a value to 0 will make the plugin ignore the threshold.)

      If we want to check the method’s time against the corresponding time in previous successful builds, we have three options: a) we can take values for comparison from the first successful build, b) take them from the last successful build, or c) compare against the average value calculated for all successful builds. If so, instead of the absolute threshold value in ms we should use one of the prefixes:
      a) F – take value from the first successful build,
      b) L – take value from the last successful build, or
      c) A – for the average value
      Then, set the tolerance to indicate by how much the time value may be exceeded, as a percentage.

Configuring the plugin

In our example, we want to track the total execution time of the Foo feature, so we add a threshold for the total time of the TestFooFeature() test. F15 means that the value for comparison (with up to 15% tolerance) must be taken from the first successful build. E.g., if during the first successful build run dotTrace measures 1000 ms total time for the method, the method’s threshold for all following builds will equal 1150 ms (1000 + 1000*0.15).

In our example, we also want to check the total time of the Goo() method as it strongly impacts the performance of the Foo feature. Checking the method’s execution time during the build simplifies our job: in case of performance issues with Foo, we will know right away if Goo() is the one to blame. As a threshold for the method, we also use the value from the first successful build, plus 15% tolerance.

5. Run the Build

Now it’s time to run the build! As we decided to use values from the first successful build for the thresholds, the first build won’t fail in any case – it is used only to set the baselines for the TestFooFeature() and Goo() methods. The time values from this build will become the “golden standard” for all subsequent builds.

  1. Run the build.
    First successful build
  2. After the build is finished successfully, we can take a look at the profiling results. Open the Build Log for this build and expand the performance testing step.
    Build Log for the first successful build
    TeamCity had no data on the methods’ execution times before the first build, so the expected values are equal to 0.
    If we run the build a second time, the expected values will be calculated based on the results from build #1:Build log for the second build

Suppose now that someone has edited the Goo() method and made it slower. (We’ll emulate this using Thread.Sleep(200).) Now, the build fails with the Performance thresholds exceeded: 2 message:
Failed build overview

The Build Log provides some info on what happened:
Build log of the failed build

As we instructed the plugin to save a performance snapshot in case of any issues, it has stored the archive with the snapshot in the artifacts folder:
Snapshot in artifacts

Now, we can analyze the snapshot and find the exact cause of the performance flaw:
Snapshot in dotTrace

Note that all values are reported as TeamCity statistic values, so you can build trend graphs for the measured time values if you like. To do this, open the Parameters tab of any build and switch to Reported statistic values:
Statistic values

Click View trend for a particular parameter to see its diagram of changes:
Statistics trend


If you use continuous integration in your development environment and it involves performance testing, don’t hesitate to try the dotTrace plugin. We’re just getting started with it! In future releases we plan to integrate the plugin right into TeamCity’s unit test runner types.

Profile with pleasure!

Posted in dotTrace Tips&Tricks, How-To's | Tagged , , | 8 Comments

TypeScript and JavaScript in ReSharper 9.2

ReSharper 9.1 marked our first attempt at supporting the future-of-the-Web technologies:  ECMAScript 6 and TypeScript 1.5. In ReSharper 9.2 we are enhancing this support while taking a look deeper into the future by extending this support to many features of TypeScript 1.6. To make your development even more fun, now we provide support for regular expressions in JavaScript and TypeScript code. And finally, two small but useful features made their way to our TypeScript support: Import completion and Go to type of symbol.

ECMAScript 6 support improvements

ReSharper 9.2 now supports ECMAScript 6 classes, including features like Find usages, Rename, and Code Completion:

ECMAScript 6 classes support in ReSharper 9.2

To make it easier to get accustomed with new destructuring constructs, ReSharper now suggests converting some code patterns to destructuring.

For example, subsequent indexing may be turned into a destructuring declaration or assignment, as suggested by ReSharper 9.2:

Destruct declaration quick-fix

Subsequent indexing in object literal properties can also be simplified to using a destructuring and short-hand properties. You get hints that look like this:

Destruct shorthand properties quick-fix

TypeScript 1.5 support enhanced

TypeScript 1.5 introduced decorators and ReSharper 9.2 supports them:

TypeScript decorators support in ReSharper 9.2

ECMAScript6-style imports now have Code Completion for available items:

Import statement code completion in ReSharper 9.2

Navigation and Rename refactoring now work for ECMAScript6-style imports and exports too:

Import statement rename in ReSharper 9.2

Initial TypeScript 1.6 support

TypeScript 1.6 aligns even more with ECMAScript 6, and introduces support for generator functions and methods. ReSharper 9.2 supports them:
TypeScript 1.6 generators support in ReSharper 9.2

TypeScript 1.6 also introduces local types – types which can be declared within a lexical scope. This feature is now supported by ReSharper 9.2 as well:

TypeScript 1.6 local types support in ReSharper 9.2

Also, since 1.6, type aliases can be generic. This possibility is also handled by ReSharper 9.2:

Generic type aliases support

TypeScript 1.6 also introduces a new feature called type predicates. You can use a signature invocation as a type guard if the corresponding signature has a special type annotation with the “is” operator. This works structurally, so that in the “true” branch the guard accepts all types that have a subtyping relation to the provided type, and in the “false” branch the guard accepts only types that do not satisfy this criterion. ReSharper now handles this as well:

Type predicates support in ReSharper 9.2

You’ve waited for this a long time, and TypeScript 1.6 now has abstract classes, which are supported by ReSharper 9.2, too:

TypeScript abstract classes support in ReSharper 9.2

One more heavily requested feature has made its way into TypeScript 1.6, and ReSharper 9.2 now supports that, too. I’m talking about async functions and methods and the await operator:

TypeScript async await support

Note that TypeScript 1.6 language is still a work in progress, so new features may be added or something may change unexpectedly. That’s why our support for it in ReSharper 9.2 is still experimental. There are some known limitations:

  • Arbitrary expressions in “extends” clause and class expressions are not supported for TypeScript yet (but they are supported on the ECMAScript 6 side)
  • JSX syntax is currently not supported
  • Intersection types are currently not supported

New features for TypeScript

ReSharper 9.2 provides two new navigation features for TypeScript: Import completion and Go to type of symbol.

Import completion now provides you with a list of all items that are available for import:
Import completion for TypeScript in ReSharper 9.2

With Go to type of symbol, you can navigate from symbols to declarations of their types, when possible:

ReSharper 9.2: go to type of symbol

Regular expressions in JavaScript and TypeScript

ReSharper 9.2 introduces initial support for regular expressions in JavaScript and TypeScript. Now it covers regular expression literals, and provides syntax highlighting and code completion on them:

Support for regular expressions in JavaScript

Regular expression modifiers are completed as well:

Please note that regular expression editor/validation functionality for JavaScript is not available yet. We’ll extend our support for regular expressions in JavaScript in future versions of ReSharper. Stay tuned.

Enhancements to existing features

There is always room for improvement in our existing features as well. ReSharper 9.2 significantly enhances recursive type handling in TypeScript; makes code analysis in JavaScript behave better with new language constructs; provides more formatting rules for new ECMAScript 6 language constructs; and improves the performance of refactorings in TypeScript.

In ReSharper 9.2, we’ve also extended string literal highlighting to template strings, so that now escape sequences are highlighted inside them as well:

string literal highlighting in ReSharper 9.2

Enjoy the new features, and please feel free to provide your feedback. Thanks!

Posted in How-To's, ReSharper Tips&Tricks | Tagged , , , , | 13 Comments

Welcome ReSharper 9.2, ReSharper C++ 1.1 and More Ultimate Updates

This is to let you know that a fresh update of ReSharper Ultimate tools is now available for download!

This update consists of ReSharper 9.2, ReSharper C++ 1.1, dotTrace 6.2, dotCover 3.2, dotMemory 4.4 and dotPeek 1.5. Let’s take a quick look on what’s new in each of them.

ReSharper 9.2

In addition to almost 400 fixes, ReSharper 9.2 release includes:

  • Improved support for Visual Studio 2015 RTM. ReSharper 9.2 refines integration with Visual Studio 2015 RTM, addressing issues discovered in versions 9.1.2 and 9.1.3.
  • Support for Windows 10 Developer Tools. ReSharper 9.2 provides code completion for API checks and supports new Windows 10 specific constructs.
    Code completion in ReSharper Api checks
  • JavaScript and TypeScript support enhancements including full support for TypeScript 1.5 and ECMAScript 6 and support for regular expressions. Regular expression support for JavaScript in ReSharper 9.2
    Going further in supporting new language versions, ReSharper 9.2 is already aware of such TypeScript 1.6 features as local types, abstract classes, type predicates, async functions and methods and the await operator. Moreover, Go to type of symbol navigation option is now available from the Navigate to menu:
    Go to type of symbol in ReSharper 9.2
    Stay tuned for more details on how ReSharper 9.2 enhances JavaScript and TypeScript support.
  • Run configurations. This is a brand new feature that allows you to create, manage, and execute multiple run configurations in a single solution. A run configuration lets you run, profile or debug a project, a static method or any executable file. For static methods, a run configuration can be quickly created right in the editor:
    Run Configuration from a static method
    You can create multiple run configurations depending on your needs and preferences. To run or debug the active configuration, press Ctrl+F5 or F5. By default, the solution will be rebuilt, but you can also execute the active configuration without rebuilding. If you have dotTrace installed and integrated in Visual Studio, you can launch profiling from the same pop-up menu: 

    Profiling run configuration in ReSharper 9.2

  • A reworked Go to Usages navigation pop-up (which is a non-modal version of Find Usages). The Go to Usages pop-up now shows the context of discovered usages, as well as a progress bar, which can be very handy when looking at heavily used symbols.

ReSharper C++ 1.1

ReSharper C++ 1.1 comes with a variety of updates, such as:

  • Google Test support. ReSharper C++ 1.1 introduces a unit test runner for Google Test that lets you invoke tests and test cases contextually from the editor. Similar to the mainline ReSharper, it comes with Unit Test Explorer and Unit Test Sessions tool windows to view, group, filter and run unit tests, as well as to create and manage unit test sessions. You can also add individual tests to sessions right from the text editor, via the Alt+Enter contextual menu.Google test support in ReSharper C++
    Please note that profiling and code coverage options are not applicable to Google Test sessions.
  • Includes Hierarchy view helps visualize dependencies between #include directives.Hierarchy of include directives in ReSharper C++
  • Enhanced C++ core features support includes inline namespaces (С++11), binary literals and digit separators (С++14).
  • New live template macros for specifying expected types, expected variable names and the current namespace in new live templates that you create for your code bases.
  • Two new refactorings: Introduce namespace alias and Introduce field. Introduce namespace alias refactoring is available via Refactor this menu and can be applied to the initial occurrence or to all occurrences by selection:
    Introduce field refactoring allows to create a new field based on a selected expression, initialize it with the expression or from the constructor, and replace occurrences:Introduce Field refactoring in ReSharper C++ 
  • New code inspections to detect not implemented inline functions, redundant inline specifiers on a function definition and functions that can be const, as well as quick-fixes for these inspections. Automatic import now works with macros as well.
  • A set of performance improvements, most notably ensuring that quick-fixes are immediately available on solution load.

Watch this short video for an overview of what is new in ReSharper C++ 1.1:

The other tools in ReSharper Ultimate have received the following improvements:

With dotTrace 6.2 you can:

  • Analyze incoming HTTP requests of your web applications by means of a new filter in Timeline mode. You can get the exact data on how a particular HTTP request is processed.
    Incoming HTTP Requests
  • Create and profile ReSharper’s predefined run configurations with different run parameters for your startup project.
  • Instantly profile any static method in your code. Simply place the cursor on the method, press Alt+Enter, and in the action list select Debug | Profile ([profiling_type]).
  • Browse performance snapshots right in Visual Studio to delete or keep particular data for further analysis.

dotMemory 4.4 allows you to:

  • Automate the process of getting snapshots. Just set a particular condition and snapshots will be collected automatically after condition is met, such as significantly increased memory consumption or exact period of time.
    Get snapshot by condition in dotMemory
  • Enjoy recently released Sunburst diagram even more with improved navigation and performance.

dotMemory Unit framework 2.0 receives a stand-alone runner for continuous integration, and extends the list of supported out-of-the-box unit testing frameworks to XUnit, MBUnit, csUnit, MSTest, and NUnit. The latter two can also be run from Visual Studio with ReSharper.

dotCover 3.2

Adds integration with ReSharper 9.2 and a set of bug fixes. Check the release notes for more details.

Please note: Currently, MSTest coverage in Windows 10 applications developed in Visual Studio 2015 using the latest Windows 10 tools is not supported, this is scheduled for the next update.

Download them all

Here’s the obligatory big red button at the end of the post:

Get ReSharper now

Licensing and upgrade options

In terms of licensing and upgrades, here are the options available:

  • ReSharper 9.2 is a free upgrade for you if you have a valid ReSharper upgrade subscription or a per-major-version license to ReSharper 9. Updates to ReSharper C++, dotMemory, dotTrace and dotCover are free if you have a valid upgrade subscription to the respective product or to ReSharper Ultimate.
  • You may purchase a single license for ReSharper Ultimate, which includes ReSharper, ReSharper C++, dotTrace, dotCover, and dotMemory. Learn more about ReSharper Ultimate.
  • If you need a formal quote or any other assistance, you are welcome to contact JetBrains sales.
Posted in How-To's, News and Events | Tagged , , , , , , | 51 Comments

How to use JetBrains Annotations to improve ReSharper inspections

ReSharper’s analyses and inspections are already very smart, finding code smells, dead code, and potential runtime issues directly from your source code. They build abstract syntax trees, create a semantic model of your code, and construct control flow graphs for tracking values, especially nullness.

But we can make them smarter through the use of annotations.

If we know that a parameter to a called method should never be null, ReSharper can warn you to check for null before calling the method. Conversely, if we know that a method will never return null, ReSharper can warn you that any null checks on the result are redundant, and help you safely remove the redundant code. Annotations can tell us when items in a list can be null, or will never be null, or when a method is an assertion method, and any code after that method call is redundant due to the assert throwing an exception.

ReSharper inspection for null

ReSharper even uses annotations to provide extra functionality. For example, string format argument matching and regular expression syntax highlighting are enabled on methods marked with annotations, as are navigation to MVC controllers and actions:

Navigation features for MVC actions

And the advanced support for  INotifyPropertyChanged in various UI frameworks is also enabled by annotations:

Extra alt+enter menu items for INotifyPropertyChanged

So what are these annotations and how do we use them?

The good news is that the development team has already done the hard work of annotating the whole of the Base Class Library for you, so you don’t need to do anything in order to get this support when working with standard .NET Framework classes and methods.

Furthermore, extensions can also define “external annotations” for pre-compiled assemblies, such as telling ReSharper that‘s Assert methods can result in dead code, or to add regular expression highlighting for Assert.Matches.

Regular expression functionality due to method with annotation

Even better, we can use these annotations in our own code, and improve ReSharper’s analyses and inspections when working with our own types and methods. We can even include the annotations when distributing our code, so consumers of our libraries get better support in ReSharper.

Annotations are implemented with .NET attributes, so it’s very easy to add to your own source code. When running an inspection or looking to activate a feature, ReSharper will look at method calls, properties and so on, and look to see if any annotation attributes are applied to the method, parameters or return value, and use that annotation to help improve the accuracy and usefulness of the inspection or feature.

In order to use the annotation attributes, you need to include them in your project. There are several ways of doing this, targeting different usage scenarios.

The JetBrains.Annotations NuGet package

The simplest way to include the annotations is to add a reference to the official JetBrains.Annotations NuGet package. This will add a binary dependency on the JetBrains.Annotations.dll assembly, which includes all of the attributes in the JetBrains.Annotations namespace. Once added as a reference, your source code can simply use the attributes directly.

The most obvious concern here is in adding a binary reference to a third party assembly. Many developers don’t wish to add references if they can avoid it, especially not to a library that is there solely to aid source code analysis, no matter how helpful it is. Why should I deploy JetBrains.Annotations.dll to production?

Of course, the ReSharper team have already thought of this, and make use of a little-known feature of .NET attributes. All of the annotation attributes are marked with the [Conditional("JETBRAINS_ANNOTATIONS")] attribute. This is a special attribute that the compiler understands, and can be applied to all sorts of types, methods, properties, and, surprisingly, attributes. If the string argument to the annotation is not defined as a compiler symbol in your project properties, the target of the [Conditional] attribute isn’t compiled into the resulting assembly. For methods, this means any calls to that method are ignored. When applied to attributes, it means the attribute itself doesn’t get applied to the compiled target method, class, etc.

So by default, using the attributes referenced from the JetBrains.Annotations NuGet package does nothing at compile time – the resulting compiled assembly does not include a reference to JetBrains.Annotations.dll, and the attributes are not applied to any classes, methods, properties, parameters and so on. However, the attributes are still visible in the source code, and ReSharper can make use of them.

Since the annotations are not included in the final compiled assembly, this method is best suited to applications, where no one else is expected to consume the code – there is no-one who would benefit from having the annotations distributed alongside the app.

Alternatively, if your assembly is compiled with the JETBRAINS_ANNOTATIONS symbol defined, the attribute usages are compiled into the resulting assembly, as is the dependency on JetBrains.Annotations.dll – the dll must be distributed with the compiled assembly. While not the most typical scenario, it can be still be useful if creating a framework for internal consumption, where distributing or deploying the JetBrains.Annotation.dll is not an issue.

Including the source

This scenario best targets third-party frameworks. If your code is to be distributed as a NuGet package that is to be consumed by anyone, it’s not appropriate to include a binary dependency on JetBrains.Annotations.dll. It’s entirely possible that not all consumers will be using ReSharper, and the dependency becomes unnecessary, and unwanted. And using the JetBrains.Annotations package without defining the JETBRAINS_ANNOTATIONS symbol means that your consumers don’t get the benefit of the annotations that you’ve defined.

If you are distributing code for external reuse, you can include the source of the attributes directly in your project. ReSharper doesn’t mind where the attributes are defined – in JetBrains.Annotations.dll, in an external XML file, or in your own code. By default, it simply looks for attributes defined in the JetBrains.Annotations namespace. As long as the attributes exist and are applied to the code, ReSharper will use them for improved inspections and features.

To get a copy of the code, simply open the ReSharper Options dialog and navigate to the Code Annotations page. From here you can easily add a reference to the JetBrains.Annotations NuGet package, or you can copy the source of the annotations attributes to the clipboard. Once copied to the clipboard, you can paste into a new file, and the annotations are now available to be used in your own code.

ReSharper annotations options page

There are two options when copying the code: one to make the annotations conditional, and another to generate the attributes as internal (as opposed to public).

Typically, if you wish to distribute an assembly with annotations, you SHOULD NOT make the annotations conditional, and SHOULD mark them as internal.

Options for copying source

By making them conditional, the source is created with the [Conditional("JETBRAINS_ANNOTATIONS"]) attribute, and the annotations will not appear in the compiled assembly unless you define the JETBRAINS_ANNOTATIONS symbol during compilation. There is little benefit in doing this over simply referencing the JetBrains.Annotations NuGet package.

Marking the annotations as internal means that the classes are only visible to the assembly they are defined in. This is the recommended setting. If you make them public, the attributes can be used by any consumer of the assembly – they effectively become part of your published API! If more than one assembly exposes them as  public, any consumer that wishes to use annotations now has a potential for ambiguous reference errors, as there will be more than one JetBrains.Annotations namespace declaring  public attributes with the same names.

The only real reason for using public is to allow sharing a single implementation of the attributes in a solution that is not going to be consumed by third parties. Again, using the JetBrains.Annotations package makes this simpler and easier.


To summarize, if you want to add annotations to your solution or project, this is what you should do:

To use annotations in an application that no-one will reference as code: Include a reference to the JetBrains.Annotations package, and DO NOT define the JETBRAINS_ANNOTATIONS symbol. The JetBrains.Annotations.dll reference is design time only, and does not need need to be deployed with your application.

To use annotations in an assembly that is to be used by third parties: Include the attributes as source. DO define as internal, DO NOT generate as conditional. Both you and third party consumers will benefit from the annotations.

To annotate a pre-compiled assembly: Create an external annotations XML file, and distribute as an extension.


Of course, now you’ve got the annotations referenced, what attributes are there, and how do you use them? ReSharper’s excellent help site provides details on using the annotations, and provides a full reference of all of the attributes that are available.


Finally, if anyone is worried about distributing or reusing the annotations package or source code, you’ll be pleased to know that both the package and the source code are explicitly covered in section 5 of ReSharper’s license agreement, which allows you to redistribute the annotations, either in source or binary form.

Posted in How-To's, ReSharper Tips&Tricks | Tagged , , | 10 Comments

ReSharper 9.2 Release Candidate 2

Please welcome another round of Release Candidate builds including ReSharper 9.2, ReSharper C++ 1.1, dotPeek 1.5, dotCover 3.2, dotTrace 6.2 and dotMemory 4.4.

Compared to the first RC, Release Candidate 2 contains a pack of performance and stability fixes in Visual Studio 2015, improves understanding of Universal Windows Platform application code, removes a few issues with C# 6 support. Here’s the complete list of fixes in ReSharper 9.2 RC2.

We still expect to publish the final release of ReSharper 9.2 and other ReSharper Ultimate tools later this month. Meanwhile, please download and try Release Candidate 2.

Posted in How-To's | Tagged , , | 7 Comments

ReSharper 9.2 Release Candidate

We have today published Release Candidate builds of ReSharper 9.2, ReSharper C++ 1.1, dotPeek 1.5, dotCover 3.2, dotTrace 6.2 and dotMemory 4.4.

The final release of ReSharper 9.2 and the entire ReSharper Ultimate toolset is expected later this month. To help us make sure that there are no critical regressions, please download and try the Release Candidate.

This list of pending bug and performance reports is what currently separates ReSharper 9.2 from the final release. If more of you start using the Release Candidate, we might be able to locate and fix even more issues in time for the release.

As a reminder, ReSharper 9.2 will refine integration with Visual Studio 2015 RTM (including fixing as many performance problems as we can), provide support for Windows 10 Developer Tools, improve support for TypeScript (including 1.5), and introduce a non-modal version of Find Usages. ReSharper C++ 1.1 will add a unit test runner supporting Google Test.

Posted in How-To's | Tagged , , | 19 Comments

ReSharper 9.1.3 to the Rescue

Visual Studio 2015 RTM users, please be informed that ReSharper 9.1.3 is now available for download, along with corresponding updates to all other ReSharper Ultimate tools.

This update fixes the annoying editor issues that were on display in ReSharper 9.1.2 and that included inverted keyboard input, disappearing caret, and focus switching off the text editor, potentially resulting in Visual Studio crashes.

Additionally, this update fixes ReSharper’s XAML code generation features in Visual Studio 2015 RTM.

If you use Visual Studio 2015 RTM, this is a recommended update for you. If you’re on older versions of Visual Studio, namely 2013, 2012 and 2010, you can skip this update.

If you have previously applied one of the suggested workarounds to improve the behavior of ReSharper 9.1.2, we suggest that you now revert the changes so that Visual Studio uses a single UI for displaying both ReSharper’s quick-fixes and Visual Studio’s quick actions.

We would like to once again apologize for the problems caused, or, to put it the 9.1.2 way, for the psmelbor cdesua.

Posted in How-To's | Tagged , , , , | 13 Comments