Continuous Testing in dotCover and ReSharper Ultimate

Over the last couple of years, continuous testing has been the top anticipated dotCover feature. Now, the wait is finally over as dotCover 10 supports continuous testing in Visual Studio! Before we move on to the nitty-gritty details to show you how it works, let’s try to recall what continuous testing actually is.

Continuous testing

In a nutshell, continuous testing means testing ‘without interruption.’ It implies that tests are run in the background, so you have actual test results instantly, as soon as you’ve changed your code. This dramatically speeds up a developer’s workflow as there’s no need to manually rebuild the project and re-run all tests after making changes: the impacted tests are run in the background automatically (the testing session is triggered by some explicit action, e.g., saving changes).

If you practice test-driven development, the benefit is even more pronounced: the Red-Green-Refactor workflow becomes virtually seamless. All the boring routines go away, leaving you only with the fun part:

1. Write a test.
2. Write a stub.
3. Build.
4. Run the tests (they must fail).
5. Update the stub to return the expected result.
6. Build.
7. Run the tests (they must pass).
8. Write the code.
9. Build.
10. Run the tests (they must pass).
11. Refactor the code.
12. Build.
13. Run the tests (they must pass).

So, how to use continuous testing in dotCover? It’s very easy, with only three steps to follow.

1. Open Continuous Testing Session window

Continuous testing is managed via the Continuous Testing Session window. To open it, use the menu ReSharper | Unit Tests | Show Continuous Testing Session.

Continuous testing is off by default

2. Select continuous testing mode

By default, continuous testing is switched off. To make it work, select one of the modes in Mode:

Select continuous testing mode

A wide variety of combinations are available. For example, you can tell dotCover to automatically build and run dirty tests after you save the project. Or, run dirty tests only after you build the project.

What does ‘dirty test’ mean? It is the test that was impacted by code changes. For example, you have a test that covers some code, you change the code, and the test result is now obsolete, i.e. the test becomes ‘dirty.’ In addition, dotCover considers as ‘dirty’ all new tests, tests that were aborted by user (aborted), and tests that failed to complete for some reason (inconclusive).

3. Just work

Once continuous testing is enabled, you can simply start working. Initially dotCover will mark all tests as dirty.

The current tests status can be checked on the continuous testing icon in the status bar (bottom right corner of the main Visual Studio window). This handy assistant shows you whether there are any failed tests or all of them pass successfully. The Continuous Testing Session window displays the results in more detail:

Continuous testing status

As we already mentioned, your workflow with the enabled continuous testing is almost seamless. Suppose you change code that is covered by some tests and save the project (and you’ve selected the On ‘Save’ Build and Run Dirty Tests mode). dotCover builds the project and re-runs (only) dirty tests in the background:

Working with continuous testing

To navigate to a failed test, click the test in Continuous Testing Session window or click the number next to the continuous testing icon.

Failed test icon

Another option to navigate to the covering tests is to do it right from the code. Simply click on the code and select Show covering tests in the context menu. This opens the list of all tests that cover this line of code. Here you navigate to the corresponding tests or force them to run:

Show covering tests

Next steps

If you’re willing to try continuous testing right now, download and install ReSharper Ultimate.

IMPORTANT! If your tests that use external files fail during continuous testing (while being successful in a traditional unit testing session), you should properly set dotCover’s Shadow-Copy option. The following post describes in details how this option works.

Should you have any questions, please feel free to ask in the comments to this post. Your feedback is greatly appreciated!

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

ReSharper Build webinar: recording and Q&A

The recording of our recent webinar with Matt Ellis, Speeding up MSBuild: Tips, Tricks and ReSharper Build, is now available:

In this webinar Matt talks about some of the ways that help achieve faster build times in Visual Studio, including ReSharper Build introduced in ReSharper 10. The following topics are covered:

  • MSBuild refresher
  • Tips for speeding up MSBuild
  • Common sense tips
  • The CopyLocal myth
  • HintPath for references
  • Checking for slow targets and tasks
  • XAML & multi-pass compilation
  • Incremental compilation
  • ReSharper Build

Questions and Answers

There were some popular questions asked during the webinar, as well as those that we didn’t get the chance to answer on the day.

Q: How does ReSharper Build’s public API surface monitoring handle InternalsVisibleToAttribute?

A: ReSharper Build will only rebuild dependent projects if an assembly’s public API has changed. The  InternalsVisibleToAttribute allows other assemblies to see  internal types and type members as though they were public. Unfortunately, ReSharper Build doesn’t yet work with this scenario – the public API monitoring is currently only for public types and type members.

To work around this issue, you can mark the referencing projects as “always build” in the ReSharper Build options page – this disables ReSharper Build’s heuristics, and always calls MSBuild on the project, where it will rebuild, based on timestamps. The issue is RSRP-450733, if you wish to vote, track or add any further details.

Q: Can ReSharper Build be used in a Continuous Integration server or as a command line tool?

A: The current implementation is targeted at reducing the solution build time in a running instance of Visual Studio, specifically at improving the feedback cycle for edit/compile/test or edit/compile/debug. At this point we don’t have any plans to extend these scenarios to include continuous integration or other kinds of usage outside of Visual Studio.

Q: What are the impacts (if any) when using TFS with multiple developers some of which have ReSharper and some which do not?

A: None. ReSharper Build optimises the solution build for running instances of Visual Studio, by skipping projects that don’t need to be built. It doesn’t alter the project files or the solution file, or anything else that can affect other developers, or a continuous integration process.

Q: If you already have everything set up with your build using Visual Studio, does ReSharper reuse these settings? I want to make sure if I start using ReSharper the output of the build (structure, etc) will be the same.

A: ReSharper Build uses MSBuild to build the projects in your solution, just like Visual Studio does. Put simply, ReSharper Build replaces Visual Studio’s solution build management with its own, which means ReSharper Build gets to decide if MSBuild should be called for a project, or not. It does not alter the project build itself – when a project is built, the normal build process is followed.

Q: How do I force a complete rebuild when for example changing a method that is only used via reflection?

A: The “Rebuild” menu item will rebuild a selected project, or the whole solution. Also, the consuming project that is performing the reflection can be marked as “always build” in the ReSharper Build options. This disables ReSharper Build’s heuristics, and always calls MSBuild for a project.

Q: What kind of speedup do you experience with the ReSharper solution?

A: This is a tricky question to answer, because it very much depends on the scenario. If a public API is changed in a project referenced by everything else, then there isn’t much of a speedup – everything is rebuilt, and it takes as long as MSBuild normally would.

However, if the change is an internal implementation detail to the same root project, then only that project is built and the speedup is huge – seconds instead of minutes. Similarly, if a public API is changed, but the build is triggered for tests, then only the projects used by the tests are rebuilt, and this can also have a huge (positive) impact on the build time. The speedups vary, and the only way to really see how much of an improvement you’ll get is to try it with your own solutions! But it’s worth pointing out this feature was initially written to make things faster for the ReSharper solution, and the whole team uses it!

Posted in ReSharper Tips&Tricks | Tagged , , | 4 Comments

ReSharper Ultimate 10.0.1

Are you having issues with ReSharper 10, particularly in terms of unit testing, performance in web applications and/or red code in UWP applications?

If you are, please download ReSharper 10.0.1, a bugfix update which addresses all the major issues that we acknowledged last week.

As usual, the ReSharper Ultimate installer contains compatible updates to ReSharper C++, dotTrace, dotMemory, dotCover, and dotPeek.

Please comment to let us know whether the update improves ReSharper experience compared to the initial v10 release, and if there are any outstanding hot issues so that we can address them in further releases.

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

Optimizing Load Balancing in PLINQs with ReSharper Ultimate

When filtering large amounts of data, using a PLINQ instead of a sequential LINQ can provide significant performance boosts. Still, optimal parallelization is quite a complex task that depends on a variety of factors, such as the number of CPU cores, the nature of input data, and others. In some cases, a query that seems parallelizable works even slower after being transformed into PLINQ.

Optimizing a PLINQ is, first of all, the task of finding the optimal load balance between worker threads. This usually requires multiple experiments with various input data, loads, and computer configurations. By using the right tools, you can find the best solution faster. In this post we’ll explain why ReSharper Ultimate (or more specifically ReSharper with dotTrace integrated in Visual Studio) is possibly the best candidate and why it is more convenient than the standard approach of measuring overall query time.

Sample application

Suppose we have a large project with many subsystems and we’ve just implemented a new feature that allows searching for a specific string in files stored inside zip packages*. Our application will use it to find particular files in numerous zips.

*This example, as well as the entire post, is inspired by PLINQ performance problems we faced when processing multiple NuGet packages in ReSharper. However, this post is not about optimizing a specific algorithm; it’s more about giving you a basic understanding of how you can analyze PLINQ performance with ReSharper Ultimate.

Our feature is based on the ZipPackage class (representing a zip package) and the FileInZip class (representing a file inside a zip). The FileInZip class provides the ContainsString method that finds a particular string in the file. This allows us to use simple LINQs for searching (e.g., …where file.ContainsString(str)…). To perform the search, a FileInZip instance extracts the corresponding file from a zip package to MemoryStream. We won’t provide the exact class implementation in this post but you can get the entire example on GitHub.

Sample app classes

Creating a run configuration

Now we want to test the feature on some sample zip packages without running the entire application (remember, it’s huge). Should we create an integration test for this? No, much easier. With ReSharper Ultimate we are able to run specific static methods using run configurations (read this post for a lot more details about the feature). In a nutshell, we should write a static method that contains only the code we need. ReSharper Ultimate’s run configurations feature will allow us to run just this method in a separate JetLauncher process. In this way we can run and debug any part of our code by isolating it from the main application. For example, anywhere in our project we can create the following static method:

Then we just use Alt+Enter on the method and select Debug | Run:Method's action list

This opens the Run Configuration Properties window. Clicking Save & Execute will run the method (under the JetLauncher process) and save the particular run configuration for future use.

Run configuration properties

Our method writes the result to the debug output. Debug output

OK, the algorithm works as expected, but how can we measure its effectiveness? Let’s profile our method! If you have ReSharper Ultimate (or both ReSharper and dotTrace) installed on your machine, you can profile any run configuration. So, all we need to do is start profiling the run configuration we’ve just created.

Profiling run configuration

To profile a static method, we once again use Alt+Enter on the method and select Profile (<profiling type>)*, where <profiling type> is the type of profiling that will be used by dotTrace. We’ll use the Timeline profiling type as it not only provides time data for method calls but also binds them to the timeline, which is extremely important when analyzing multi-threaded applications.

*The default profiling type can be selected in Performance Snapshots Browser which can be opened via ReSharper | Profile | Show Performance Snapshots… Profile through the action list

This runs profiling and automatically takes a performance snapshot when the process completes its work. Then the collected snapshot is opened in dotTrace Timeline Viewer.

If you’re new to Timeline Viewer, find more details about it here. In a few words, it is a part of dotTrace that allows you to slice and dice the collected snapshot data using filters. For example, select time intervals where a certain event takes place (UI freeze, GC and so on) and find out what methods stand behind that. Or, vice versa, select time intervals where a specific method is executed and see what subsystems are working at this moment.

If we now take a look at the Threads Diagram in Timeline Viewer, we’ll see that the profiled static method utilizes just one Main thread (as expected) and requires about 70 seconds to complete:Threads Diagram showing sequential LINQ

The Top Methods filter shows that the highest own time belongs to the Ionic.Crc.CRC32.SlurpBlock method. This is kind of expected as this method is responsible for zip extraction (the app uses the DotNetZip library to work with zip packages).

Top Methods and Call Tree

As 70 seconds is too long for us, we decide to parallelize our LINQ so that multiple threads can unzip packages at the same time.


The most obvious solution is to add the AsParallel method to the input sequence in our LINQ.

After profiling, we see that this solution kind of works – overall execution time has decreased to 39 seconds. Still, that result is far from ideal. The Threads Diagram shows that the data is split among 8 threads and, while some threads do most of the job, others complete their work much earlier.Timeline Diagram for PLINQ with AsParallel

So, why does this happen? Let’s use dotTrace’s filtering capabilities to find out the root cause. Our input data are zip files stored on a disk, so we should take a look at how threads treat these files. To do this, we simply turn on the File I/O filter in Interval Filters. Now, all other filters show the data only for the time intervals where file I/O takes place.

Threads Diagram with applied File IO filter

The File I/O: File Name sub-filter shows how File I/O time is distributed among specific files:

File IO File Name subfilter

The sub-filter states that some files require more time than others. If we now turn on a filter by a specific file, we’ll see that each zip file is processed by exactly one thread:

Threads Diagram with applied File IO File Name filter

Therefore, the problem lies in the zip-per-thread load partitioning. As zip files have different sizes, threads take different amounts of time to process them. This means we need to implement partitioning in a way that lets each thread extract files from any zip package.

Custom partitioner

Our solution is to create a custom partitioner that will split the input data into equal chunks. In our case the partitioner must provide not zip packages to PLINQ, but the files inside these packages. For this purpose, we can try using a “default” partitioner, an instance of the Partitioner class. We just need to prepare the input data for the partitioner (files in zips) and specify whether we want to use dynamic or static partitioning (this is specified in the partitioner’s Create method).

With dynamic partitioning, it will try to balance the load dynamically so files will be provided to threads as they are requested. This can provide a speed boost on computers with many cores. The static partitioner prepares all chunks before the start, resulting in a lower overhead. This approach may be faster on computers with only a few cores.

Let’s try dynamic partitioning:

After we profile the method, we can see that the load is now much more balanced. The makes the method take only 29 seconds to complete, which means a 10-second (25%) improvement. The default static partitioner on an 8-core computer shows almost the same results:

Threads Diagram for default dynamic partitioner

As we can see on Threads Diagram though, the partitioning is still not perfect as some threads complete their work a little bit earlier than the others. This happens because the “default” partitioner knows nothing about the internal structure of our input data (text files).

The problem is that bigger files require more time for extraction. This means we need to fill the chunks not based on the number of extracted files, but on their size. We can try to solve this task by creating our own static partitioner. Such a partitioner must be based on the Partitioner class and must implement the GetPartitions method, which returns enumerators for the given number of partitions.

On an 8-core machine, our custom partitioner works a little better than the default partitioners. The load is more balanced now with about 10% additional improvement (from 29 seconds down to 26).

Threads Diagram for custom static partitioner

What next? The only way to ensure your PLINQ works as fast as possible is to test it on as many configurations as possible. For example, if we try all the partitioners we’ve just created on a 4-core PC, we’ll see somewhat different results:

Threads Diagrams on a 4-core PC

While the default static and dynamic partitioners are still close, the custom one increases its lead. It takes 30 seconds, which is about a 15% improvement compared to 35-37 seconds. The small difference in absolute time values between 8-core and 4-core PCs may be explained by the large number of garbage collections which block worker threads (as our algorithm allocates a LOT of memory for zip extraction). Excessive GCs would make a good target for optimization too, but that’s a story for another post.

As you can see, PLINQ performance offer rich opportunities for experimenting, and ReSharper Ultimate can help a lot. We hope you find this post helpful and give a try to ReSharper Ultimate features on your own.

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

ReSharper 10 critical issues and fix schedule

Following the release of ReSharper 10.0 last week, we have received a great deal of feedback, and unfortunately a lot of it was negative.

Upon analyzing the feedback, it looks like unit testing is the most affected area. Hot issues include the Output pane in Unit Test Sessions that might not show any results upon running your tests (RSRP-450266), as well as Visual Studio hanging when you debug MSTest-based tests (RSRP-449577). Both issues are going to be fixed in the next bugfix update, 10.0.1, that we expect to release soon, hopefully this week.

Speaking of other problem areas, ReSharper 10.0 is known to show red code in some perfectly compilable Universal Windows Platform (UWP) projects (RSRP-450057, a private build and workarounds are available in comments to the issue). This is already fixed internally, and a fix is also going to make it into 10.0.1.

We’ve seen license activation issues related to connecting your ReSharper installations to your JetBrains Accounts but these were hopefully fixed with a redeployment of the JetBrains Account application early last week. If you’re still experiencing license related issues with ReSharper 10, make sure to read this article for ways to resolve or work around them.

We’re also fixing miscellaneous performance problems as soon as we can reproduce them. Particularly, heavy performance issues that could affect all kinds of web sites and web applications were fixed and a fix will be available in 10.0.1.

Apart from the bugfix update (10.0.1) that we’re hoping to roll out as soon as possible, we have another update (10.0.2) scheduled for mid-December that will target any considerable regressions left following 10.0.1.

Apologies for the struggle caused by 10.0 to many of you. If necessary, you can revert to ReSharper 9.2 or another recent release until we’ve released the upcoming update.

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

Welcome ReSharper Ultimate 10 RTM

We are here to let you know that the final release of ReSharper Ultimate 10 is now available for download!

ReSharper Ultimate 10

As described earlier, all ReSharper Ultimate family tools now share a common version number to simplify dealing with compatibility issues, so please welcome ReSharper 10, ReSharper C++ 10, dotTrace 10, dotCover 10, dotMemory 10 and dotPeek 10.

Watch this video for an overview of what is new in ReSharper Ultimate 10:

Here is a quick recap of what is new for each of the tools, if you prefer text.

ReSharper 10

In addition to around 450 fixes, highlights of ReSharper 10 include:

  • ReSharper Build is a new 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
    Read this post for more details on ReSharper Build.
  • Built-in postfix templates. One of the most popular plugins gets integrated into mainline ReSharper. Postfix templates allow reducing backward caret jumps while typing C# code. For example, you can start with an expression and proceed to wrap it into an if statement to check whether it returns true. Another template allows you to throw an exception if certain condition is met. Postfix templates
  • Usage-aware Go to Declaration. ReSharper 10 extends the functionality of Go to declaration (as well as Ctrl+click) so that you can also use the shortcut to look up for usages. In case you have one declaration and one usage, you can use Go to declaration to simply switch between them. If you have multiple usage of a symbol, subsequent Go to declaration hits will take you to further found usages of the symbol, one usage at a time. Navigation between usages is aided by a Find Usages-like pane that enumerates found usages, contains additional controls to mouse-click between usages, and helps you flush all found usages to the regular Find Results window if you like. Usage-aware Go to declaration
  • Code style improvements. ReSharper 10 comes with a set of changes aimed to simplify configuration of and complying with code style settings. Inspection severity can now be configured right from the Alt+Enter menu, without using a modal window. Find similar issues 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 same old Alt+Enter menu. 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.
  • Refined Stack Trace Explorer. Stack Trace Explorer was basically rewritten from scratch in ReSharper 10. This enabled Stack Trace Explorer to provide links to types in addition to methods and to parse more types of data, including WinDbg GCRoot dumps, Visual Studio Call Stack tool window contents and dotTrace snapshots.
  • NUnit 3.0 Beta 5 support. As the new major version of NUnit is approaching release, we have laid the groundwork to support it in ReSharper unit test runner. We will make more changes in order to support the release version of NUnit 3.0, though at this point the latest Beta 5 is supported.
  • JavaScript and TypeScript support improvements. Support for JSX syntax is now available in .js, .jsx and .tsx files to streamline React development in ASP.NET applications. Code completion, all ReSharper regular context actions for HTML and JavaScript, navigation to declarations and search for usages, as well as a couple of refactorings are available as well. JavaScript regular expressions that were originally supported in ReSharper 9.2 are now covered in more detail. TypeScript 1.6 support has been finalized with the addition of intersection types and class expressions. Moreover, code completion for JavaScript is now aware of types from JSDoc comments.
  • UWP device family-specific views. Universal Windows Platform enables using device family-specific XAML views to provide different UI for different types of devices. ReSharper 10 learns to handle this with dedicated code inspections, quick-fixes and context actions.Code inspections for UWP device family
  • Google Protocol Buffers (Protobuf). ReSharper 10 starts to provide support for .proto files. This includes syntax highlighting, code analysis, code completion and navigation for both 2.x and 3.0 Protobuf versions.

ReSharper C++ 10

ReSharper C++ 10 comes with 200+ fixes and a variety of enhancements:

  • Improved support for C language. ReSharper C++ 10 provides full support for C99, including designated initializers. C11 is supported to the same extent that Visual Studio supports it. Code completion and some context actions that are specific for C language are introduced with this release as well.Code completion for C in ReSharper C++
  • New context actions. There is a new action to create a derived class when standing on a class declaration. Other new context actions help replace decltype with the underlying type, as well as substitute a template type alias.
  • New code inspections and quick-fixes. We’ve introduced a new code inspection that detects whether a class needs a user defined constructor with a quick-fix to generate it. Another new code inspection detects uninitialized base class in a constructor and offers a quick-fix to initialize it. Additionally, we added quick-fixes for mismatched class tags highlighting, a quick-fix to add a template argument list and a quick-fix to make base function virtual.Make base function virtual quick-fix
  • ReSharper C++ 10 inherits the updated usage-aware Go to declaration mechanic from the mainline ReSharper. From now on you can use the single shortcut not only to switch from declaration to definition, but also to navigate through usages.
  • Code generation. ReSharper C++ 10 allows generating definitions for a function inline. We’ve also added support for generating Google Mock stubs for those who use Google Test framework.
  • Performance was one of our priorities for this release, and as a result ReSharper C++ 10 works significantly faster on solutions that had already been cached.

dotCover 10

The main highlight for dotCover 10 release is the long-awaited Continuous Testing functionality. Following an initial code coverage analysis of your solution, dotCover 10 learns to track your code changes, figure 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.
Continuos testing session in dotCover 10

dotTrace 10

dotTrace integration in Visual Studio has been considerably improved with this update. With dotTrace 10 when you choose to profile your startup project from Visual Studio in Timeline mode, you can view the resulting snapshot right in Visual Studio, using the Performance Profiler tool window. You can select a particular time frame to investigate and drill into, make use of several filtering options, as well as export and save snapshots, all without leaving Visual Studio.
dotTrace 10 Timeline viewer in Visual Studio

dotMemory 10

dotMemory 10 introduces a new contextual option that lets you navigate from a type in an object set to its type declaration in an open Visual Studio instance. If the target type is a library type, this triggers ReSharper’s decompiling functionality and opens decompiled code in Visual Studio.
dotMemory 10 Find declaration in VS action

In addition, dotMemory receives a start view similar to dotTrace Home. The new dotMemory Home screen can be used as a starting point to memory profiling that lets you launch a new local or remote profiling session, attach to a running process, configure a profiling session and more.

dotPeek 10

dotPeek 10 delivers one of the most heavily requested features: you can now navigate to IL code from any point in the C# decompiled code viewer. IL code can be shown in a separate tool window or as comments to C# decompiled code.

IL viewer in dotPeek 10

Find Usages in dotPeek now works asynchronously, similarly to how it does in recent versions of ReSharper. This means that even if you started to look up for usages, you can still work with dotPeek without needing to wait until it finalizes the search.

In other news, dotPeek 10 supports color themes: you can now select one of 3 default themes, or choose to synchronize your color scheme preference with Visual Studio settings.

Get ReSharper Ultimate 10

Licensing and upgrade options

In terms of licensing and upgrades, some changes are introduced with this release:

  • ReSharper 10 is a free upgrade for you if you have a valid ReSharper upgrade subscription. ReSharper C++ 10 is free if you have a valid upgrade subscription to ReSharper C++.
  • In case your upgrade subscription expired, you can now subscribe to ReSharper, ReSharper C++, ReSharper Ultimate or All Products pack with a discount and get the second year of subscription for free. For details on how new subscription-based licensing works, please see JetBrains Toolbox.
  • Starting from November 2, 2015 dotTrace, dotCover and dotMemory are only licensed as part of ReSharper Ultimate. Read this post for details.
  • If you need a formal quote or any other assistance, you are welcome to contact JetBrains sales.
Posted in News and Events | Tagged , , , , , , | 67 Comments

ReSharper Ultimate EAP 7

Today we have prepared a fresh ReSharper Ultimate EAP build. EAP 7 is mostly about fixes and stabilization across all the tools from ReSharper Ultimate family, and we encourage you to download and try it if you didn’t have a chance to do it earlier. As ReSharper Ultimate 10 release is just around the corner, we need your feedback as soon as possible, so if anything is not working, please let us know.

Here is quick wrap up of what this build has to offer:


  • Improved performance of Unit Testing, along with several important bug-fixes for issues discovered in previous EAP builds.
  • Updated default severities for some of the code style inspections.
  • Template completion (Shift+Enter on selected method or constructor)
  • A set of fixes related to UWP support for the latest update of Windows developer tools.

Here is the full list of fixes in ReSharper 10 EAP 6 and EAP 7.

ReSharper C++

In addition to a set of fixes, ReSharper C++ speeds up on solution load for already cached solutions and receives support for char16_t and char32_t built in types.


dotCover comes with several fixes for Continuous Testing, and a fix for the issue with huge icons in high DPI.


dotMemory receives the start screen similar to dotTrace Home. The new dotMemory Home screen can be used as a starting point to memory profiling that lets you launch a new local or remote profiling session, attach to a running process, configure the profiling session and more.
dotMemory start screen
Every application type will offer different settings for running and profiling the application. Selecting the Advanced checkbox will provide additional options, such as filtering for child processes we might want to exclude from profiling session.

What’s next?

We plan to publish more EAP builds later this week, since the release is scheduled for November, 2. Please report any problem you might encounter to issue trackers of affected products. Here are the corresponding links for your reference: ReSharper, ReSharper C++, dotTrace, dotCover, dotMemory, dotPeek.

Posted in News and Events | Tagged , , , , | 11 Comments

ReSharper Ultimate 10 EAP 5

Last Friday saw the release of a new ReSharper Ultimate 10 EAP build. Highlights of EAP 5 include notable changes in ReSharper and dotMemory, as well as dotTrace integrating its Timeline profiling functionality right in Visual Studio.


Revised Stack Trace Explorer

ReSharper’s Stack Trace Explorer tool window has been basically rewritten from scratch. Among other effects, this enabled Stack Trace Explorer to:

  • Provide links to types in addition to methods.
  • Parse more types of data, including WinDbg GCRoot dumps and Visual Studio’s Call Stack tool window contents.

Stack Trace Explorer

The update to Stack Trace Explorer also affects ReSharper’s Unit Test Sessions tool window where it is used to display call stacks in unit test output and provide links to relevant source code locations.

Support for Google Protocol Buffers (Protobuf)

You don’t use Google Protobuf too often but when you do, you can now lean on ReSharper to ensure proper IDE support in .proto files. This includes syntax highlighting, code analysis, code completion and navigation.
Support for Google Protocol Buffers
In terms of Protobuf versions, both 2.x and 3.0 syntax is supported.

Other changes

Other notable changes in ReSharper 10 EAP 5 include:

  • More C# code style inspections and quick-fixes, such as those helping get rid of redundant parentheses, or add parentheses to disambiguate precedence.
  • Support for different kinds of JSDoc type annotations, including symbol names, unions, parameter annotations, type definitions and callbacks.

Here’s the full list of fixes in ReSharper 10 EAP 5.


Timeline profiling integrated in Visual Studio

dotTrace integration in Visual Studio has traditionally been sketchy but here’s an important step to change this. From now on, when you choose to profile your startup project from Visual Studio in Timeline mode, you can view the resulting snapshot right in Visual Studio, using the Performance Snapshots Browser tool window.
Timeline profiling in Visual Studio

Available controls include the timeline view that you can zoom into, as well as the call tree, thread and thread state selectors, event filters, and a switch to focus on user code.

Whenever necessary, you can choose to open a particular snapshot in the standalone dotTrace Timeline Viewer.


Navigate from memory snapshot to code in Visual Studio

Starting from this EAP, dotMemory introduces a new contextual option that lets you navigate from any object set to its corresponding type in an open Visual Studio instance. If the target type is a library type, this triggers ReSharper’s decompiling functionality and opens decompiled code in Visual Studio.
Go to type declaration in Visual Studio from dotMemory

Wrapping it up

As usual, this is where you can download ReSharper 10 EAP from.

Experiencing issues with the EAP? Please report them to issue trackers of affected products as we’re right now trying to stabilize everything that’s inside so that the expected November 2 release is as smooth as possible.

Issue trackers are as follows: ReSharper, ReSharper C++, dotTrace, dotCover, dotMemory, dotPeek.

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

All ReSharper Ultimate tools bumped up to version 10

If you have started to use ReSharper 10 EAP (build 4 or later), a strange detail might have caught your attention:

Several v10 products as seen in the ReSharper Ultimate installer

Wut? Is it a bug? OK, ReSharper was meant to be versioned 10 but other Ultimate tools clearly weren’t.

Well, there’s no mistake. We have decided to align versioning across the entire ReSharper Ultimate family starting with ReSharper version 10.

Also, by virtue of this uniform versioning, we can finally refer to the entire set of tools as ReSharper Ultimate 10.

Granted, it’s bizarre for some products to make a switch like this: for example, dotPeek jumps from 1.5 to 10 and ReSharper C++ leaps from 1.1 to 10.

However, there’s a legitimate reason behind this.

Before last year, ReSharper, dotCover, dotTrace and other JetBrains .NET tools used to evolve more or less independently from each other, without much coordination. This all changed with the advent of ReSharper Ultimate, which brought a common installer, a common set of assemblies shared between all tools, a synchronized release cycle and unified licensing.

Along with all the advantages of the new approach, it brought a new restriction: if you were to use multiple tools from the ReSharper Ultimate pack, you could only use versions released simultaneously. Installing, say, ReSharper 9.1 released in April 2015 alongside dotMemory 4 released in December 2014 wasn’t possible anymore: you had to make sure that versions you installed were aligned in terms of release dates.

However, disparate versioning used by different ReSharper Ultimate tools didn’t help anyone figure out which versions were compatible and which were not.

Taking all this in mind, we sat down and thought, which of the two main considerations behind versioning was more relevant at this point in ReSharper Ultimate history: a way to indicate which releases of each particular product had more important changes than its other releases, or a way to unequivocally identify which ReSharper Ultimate products were guaranteed to work alongside each other.

In the end, although it wasn’t apparent to everyone and took quite a while to agree on, we figured that the latter was more important today and going forward.

In practical terms, the new versioning should be read as follows:

  • ReSharper Ultimate products having the same version (10 and onward) are guaranteed to be compatible.
  • Advancing a version number (10 to 10.1 or 10.2 to 11) will usually indicate considerable changes in the flagship product, ReSharper. Other Ultimate products may or may not receive comparable changes but will still advance their version numbers accordingly in order to make absolutely clear that they are expected to work with each other.

While we realize that this change is somewhat unorthodox, we’re really hopeful that in practice it helps you figure out more easily which combinations of ReSharper Ultimate tools are safe to be used together.

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

Introducing ReSharper Build

ReSharper has always wanted to speed up your code editing, refactoring and navigation. ReSharper 10 now wants to speed up your build.

ReSharper Build is a new feature in ReSharper 10 that will reduce the time it takes to build your solution. It replaces Visual Studio’s build management with a system that applies heuristics to only build projects that need updating. Note that it doesn’t replace MSBuild — your projects are still built normally. They’re just not built as often.

In this post, we’re going to take a deep look at how ReSharper Build works, and how you can make use of it in your own solution.

The benefits of a faster build are obvious — we all want to speed up the development feedback cycle. No one wants to be interrupted when they’re in the flow, and a slow compile can be a real productivity killer. The quicker we can get a solution rebuilt, the sooner we can get feedback from our tests, and the sooner we can move on to new code, or fix up tests. And if this happens quickly enough, we stay in the zone, and remain productive.

Furthermore, ReSharper Build is also an important part of another new feature — Continuous Testing. This is a feature of dotCover and ReSharper Ultimate which intelligently runs only the subset of tests that cover the code that you’ve just changed. In order to be able to do this, we need to be able to build the changed code as quickly and efficiently as possible. We’ll take a closer look at Continuous Testing in a future blog post.

Some of you power users might recognize ReSharper Build’s heritage — it’s the latest evolution of a (somewhat) hidden/internal feature that we’ve been using on the development team for several years. When the uber-solution to everything that makes up ReSharper Ultimate is 600 projects, and the everyday solution for feature development can be as large as 300 projects, you need something to speed the build up!

How does ReSharper Build work?

Put simply, ReSharper Build manages the build process, and decides if each individual project needs to be built, or not. When building a solution, if a project doesn’t need to be rebuilt, it is intelligently skipped — what’s faster than doing nothing?

There are three main optimisations:

  1. All build management happens out of process. Visual Studio has been moving more of the build pipeline out of process in recent versions, but even in Visual Studio 2015, the core build management is still hosted in-process. ReSharper Build is hosted out of process, meaning that Visual Studio remains snappy and responsive while a build is running.
  2. Efficient timestamp monitoring. MSBuild supports building incrementally, by comparing the timestamps of inputs and outputs of a target — it they are up to date, the target isn’t run. But an MSBuild process must still be run so that it can check the inputs of outputs of each target and check all of the timestamps — this gives us an overhead to do nothing!

    ReSharper Build maintains a dependency graph of inputs and outputs to tasks, targets and projects, and efficiently monitors the file system for changes. If a build is requested, ReSharper Build already knows if the timestamps are up to date, without having to invoke MSBuild. If it’s up to date, don’t build it.

    This optimisation alone can greatly improve the time your solution takes to build — but we can go one better.
  3. Public API surface monitoring. Traditionally, if a project is edited and rebuilt, Visual Studio and MSBuild will also rebuild all other projects that reference it. If we’re changing the public API of an assembly, then this is a good thing — referencing projects need to know if we change the name of a method, add parameters or remove an interface. But if we’re only changing the internal business logic of a class, we’re rebuilding the referencing projects unnecessarily — the generated code in the referenced assemblies won’t change.

    When a project is built, ReSharper will scan the just compiled output assembly. If its public API hasn’t changed, then ReSharper Build knows that it doesn’t need to build any of the referencing projects, and they are intelligently skipped. This has a huge impact on larger solutions. If a change is made to the business logic of a root assembly, then traditionally, that would require the rest of the solution to be rebuilt. ReSharper Build will only rebuild the root assembly, and skip the rest.

How do you use it?

It’s very easy. Once enabled, ReSharper Build replaces and overrides the standard Visual Studio build process, and is invoked whenever a build is required — building, rebuilding or cleaning the solution, running or debugging the project, or running unit tests. ReSharper Build is disabled by default, meaning you have to opt-in to the new build management (there are some edge cases that can cause issues, particularly custom build steps, so we’ve decided that you need to make an explicit step to opt-in. See below for more details).

You can enable ReSharper Build by first displaying the ReSharper Build & Run tool window, from ReSharper → Windows → Build & Run.

ReSharper Build tool window showing link to enable ReSharper Build

If ReSharper Build is not enabled, the tool window will show you that Visual Studio’s build process is being used, and provide a link to “Enable ReSharper Build”. You can also enable ReSharper Build and change the settings through ReSharper → Options → Build, and if you use the Save To button, you can enable/disable on a per-solution basis.

ReSharper Build and Run showing the projects colour coded for status

Once enabled, the ReSharper Build & Run tool window will show all of the projects in the solution, as coloured boxes. The colour of each box represents the state of the project, such as not requiring build, excluded from this build, skipped, built with errors, or successfully built. There are several more states available, and hovering the mouse over a project will display a tooltip explaining the state.

ReSharper Build and Run tool window showing tooltips for status

Once a build completes, any output from the build (errors, warnings, info and messages) are displayed in the ReSharper Build Results tool window, from which you can double click to navigate to the warnings and errors. We are still working on the UI during the EAP, so expect this window to change, as we will be adding support for keyboard shortcuts, and also grouping results.

Build results list tool window

Update for RTM: The Build Results tool window was removed from the final RTM release of ReSharper 10.0. We didn’t get the design and feature set finalised and working well enough to be included in this release. Instead, we have rolled back to the prototype implementation, which will automatically display build results as a tab in the Find Results window. While this location might seem a little surprising, ReSharper displays the window automatically, and whenever you double click one of the projects in the Build & Run tool window. Furthermore, the Find Results implementation offers more features, including grouping, filtering and keyboard shortcuts. The standard Visual Studio F8 and Shift+F8 shortcuts will navigate the errors, as will ReSharper’s standard previous/next shortcuts Ctrl+Alt+PageUp/PageDown (Ctrl+Alt+Up/Down for IntelliJ shortcut users). We will be re-evaluating how we display build results for a future release.

ReSharper Build overrides the standard Visual Studio build commands, meaning it gets invoked from the normal build keyboard shortcut, which will build the whole solution. Similarly, rebuild and clean keyboard shortcuts will build the whole solution.

When running tests, launching an application for debugging, or right clicking and selecting Build on the project’s context menu, ReSharper Build is invoked on a subset of the solution, and only processes those projects. Any other projects that need rebuilding are ignored, and marked in blue, showing they will be rebuilt in the future.

ReSharper Build tool window showing projects not built due to selection

Similarly, ReSharper Build is available under the ReSharper → Build menu option, which allows for building, cleaning and rebuilding the solution. It also offers menu items to just build, rebuild and clean the current selection. You can also cancel the current build, if it’s taking too long (although we don’t expect this to get used much).

ReSharper Build menu items

Update for RTM: The ReSharper → Build menu item has been removed – all options are already available on Visual Studio’s Build menu, with the exception of building a selection. This can be achieved from a project’s context menu, or automatically by ReSharper when building before running tests.


ReSharper Build can be configured from ReSharper Options (ReSharper → Options → Build, or by clicking the “spanner” options icon in the ReSharper Build & Run tool window). You can set which version of MSBuild to use (Visual Studio’s, by default) and how many MSBuild processes to run for parallel build.

ReSharper Build options page

You can also configure which projects should never be built, and which projects should always be built. These two options can be very useful.

Excluding a project means it won’t get rebuilt, ever, even if source files are out of date or a referenced project has public API changes. This is quite drastic, and can lead to uncaught compilation errors, but can be useful to temporarily exclude a project that is slow to compile, and not used in your current development task. It’s similar to unloading a project in Visual Studio so that it doesn’t compile, but the source files are still available to ReSharper to allow for navigation and refactoring. We recommend reenabling and rebuilding before committing to source control, or using Solution Wide Analysis to show compile errors as you type!

Marking a project as “always build” tells ReSharper Build to never apply heuristics to this project, but to always pass it to MSBuild. This does not mean that the project will always be rebuilt and recompiled, but it means MSBuild is always called — MSBuild will still check timestamps and might perform an incremental build. This is useful for projects that have custom build steps that ReSharper Build can’t track (although it would be better to rewrite the custom build steps as proper MSBuild targets that support incremental build. See below).

Technical limitations

There are a couple of technical limitations that are due to ReSharper Build being based on MSBuild:

  • Non-MSBuild projects. ReSharper Build can’t work with project types that are not MSBuild based. This includes Web Sites (folder based projects, not MVC web applications), WinJS applications and DNX applications. These projects will fall back to the standard Visual Studio build process, although the rest of the projects in the solution can continue to use ReSharper Build.
  • Custom build steps. Typically, custom build steps (including pre- and post-build steps in C++ projects) are the equivalent of calling a batch file, with several command lines being executed to e.g. copy files to the output directory. These are a black box as far as ReSharper Build is concerned — it doesn’t know what’s happening in the custom build step, so can’t track the input and output. Furthermore, if the project is skipped, the build step doesn’t run, which could cause issues with the build (this is the main reason ReSharper Build is disabled by default).

    However, custom MSBuild targets and tasks WILL work with ReSharper Build, as long as the custom target and task supports incremental building, with a list of inputs and outputs that can be monitored for timestamp changes. Converting a naive custom build step to custom targets is highly recommended in order to get good results with ReSharper Build.

    If a custom build step cannot be replaced, the project can be added to the list of projects that should be “always built”, without having heuristics applied, meaning they are always passed to MSBuild, and MSBuild’s standard incremental build process will run. This can be configured in the ReSharper → Options → ReSharper Build page.

Known issues

As well as continuing to work on the UI, there are still a couple of known issues. If you encounter any other issues, PLEASE let us know!

  • NuGet package restore is not currently supported. Right now, ReSharper Build does not trigger NuGet’s package restore functionality. To restore packages, go to the NuGet package UI, or temporarily switch to the Visual Studio build process using the “cog” icon in the ReSharper Build & Run tool window.


  • Does this work with Copy Local? Yes.

    ReSharper Build also tracks copy tasks, and will replay them if timestamps have changed. So a project that is skipped will still get the latest version of any modified referenced assemblies in its output folder.

    For even faster build times, we recommend building to a single bin folder (and NOT disabling Copy Local). This results in far fewer files being duplicated and copied around, and as an added bonus, reduces the number of files being monitored by ReSharper Build for timestamp changes.
  • Does this work for changes in resource files? Yes.

    ReSharper Build monitors the timestamps of all inputs to targets, rather than changes to just source files. Any resource files (images, xml files, etc.) that are modified are flagged as timestamp changes, so the project is rebuilt.
  • Does this work with C++, F#, etc? Yes.

    ReSharper Build monitors the inputs and outputs of targets and tasks, and can apply the timestamp heuristic to these projects. It can apply the surface API heuristic to any CLR based project — ReSharper Build calculates the public API surface from the output assembly, rather than the source of the project, so can monitor any CLR based assembly for API changes. However, please remember that custom build steps are a black box that ReSharper Build cannot track. If your project has a custom build step, including C++ pre- and post-build steps, ReSharper Build cannot know when they should be run. You can either rewrite the custom build steps to use proper MSBuild targets and tasks, or exclude the project from heuristics in the options.

    Of course, if you encounter a project that doesn’t play nicely with ReSharper Build, please let us know.
  • Does this work with strong naming? Yes.

    When referencing an assembly, the version is embedded as part of the reference. When an assembly is strong named, the version numbers must match exactly, or assembly loading will fail. This means referencing assemblies need to be recompiled, even if the public API hasn’t changed.

    ReSharper Build considers the assembly version to be part of the public API. If the version changes, referencing assemblies are recompiled.

    The AssemblyVersionAttribute specifies the version of the assembly. If it’s set to a static value such as "", the version doesn’t change with each compile, and ReSharper Build’s optimisations can be applied. However, if the assembly version is in the form "1.0.*", the version is updated on each compile, and ReSharper Build considers the public API to have changed, and the surface API heuristic no longer applies.

    The default C# project template sets the assembly version attribute value to be "", which fits nicely with ReSharper Build’s optimisations. However, the managed C++ template sets the attribute value to "1.0.*", which will make ReSharper Build consider the public API as having changed. It is recommended to change the assembly version attribute to be a static value in order to get the most from ReSharper Build.
  • Does this require Solution Wide Analysis to be enabled? No.

    The public API build heuristic works on the compiled assembly, and doesn’t need to analyse source code at all. If you have excluded a project from building in the options page, Solution Wide Analysis can be very useful to capture compile errors that you wouldn’t otherwise see.
  • How does this work with Run Configurations? ReSharper 9.2 introduced Run Configurations, which are ways of defining targets to run and debug. These can be running an executable with different command line parameters, launching a project, or even debugging a static method.
    ReSharper Build tool window showing run configurations menu
    Naturally, ReSharper Build integrates nicely with Run Configurations, providing a drop-down of different configurations in the ReSharper Build & Run tool window. From here, you can select the default configuration that will happen when you run or debug, or define new ones.

And finally, a small tip to finish up — ReSharper Build monitors the public API surface of your assemblies. To reduce unnecessary builds, consider using “internal” instead of “public”. If a class, interface, method, etc. isn’t actually required to be public, making it internal reduces the API surface being monitored, and will reduce the number of unnecessary rebuilds.


We are very excited to launch a new feature such as this. We’re hoping it will have as much of a positive impact on your build times, as ReSharper has had on your development experience.

Please download the latest EAP and try it out with your projects, and PLEASE let us know if you encounter problems. This is why we run the Early Access Program — to get feedback on products before they’re finalised, to find issues before we release. Let us know if it’s working for you, and especially let us know if it doesn’t!

Posted in ReSharper Tips&Tricks | Tagged , , | 70 Comments