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 , , | 65 Comments

Details on dotTrace, dotCover, dotMemory licensing changes


  1. Starting November 2, dotTrace, dotCover and dotMemory will only be licensed as part of ReSharper Ultimate
  2. If you’re not licensed to dotTrace, dotCover and/or dotMemory, you can safely ignore this post
  3. There are reasons behind this change
  4. To figure out what this change means to you and compare your license maintenance costs before and after the licensing change, locate yourself in one of 4 major affected groups of customers
  5. If you’re only using dotCover on a CI server, take note that we’re preparing a free license to dotCover Command Line Tools

What’s going on?


As you most probably know, last month we at JetBrains have announced a forthcoming transition to subscription licensing, which is due to occur on November 2, 2015.

The change directly affects users of ReSharper, ReSharper C++, dotTrace, dotMemory and dotCover: all licenses purchased on or after November 2, 2015 will be subscriptions, with monthly and yearly billing options available. Substantial discounts are provided to convert existing licenses to the new scheme, and a new licensing option is introduced that will allow you to subscribe to all desktop products that JetBrains offers, which includes IntelliJ IDEA and its sister IDEs, as well as the entire ReSharper Ultimate product line.

For a summary of subscription licensing and pricing, please see

dotTrace, dotCover, dotMemory will no longer be licensed separately

However there’s even more change coming for customers who use JetBrains .NET tools. We have made this public on the day we revealed the subscription model but this might have been lost in the overall fuss created by the announcement. This is why we’d like to emphasize specifically that starting November 2, 2015, dotCover, dotTrace and dotMemory will only be available for purchase as part of ReSharper Ultimate subscriptions: separate licensing of dotCover, dotTrace and dotMemory will be discontinued.

Summary of licensing changes

Why are dotCover, dotTrace and dotMemory not going to be licensed separately after November 2, 2015?

This is simple and long time coming: in most cases, dotCover, dotTrace and dotMemory are purchased and used along with ReSharper.

Well aware of this trend already a year ago, we have introduced a ReSharper Ultimate license, and we’ve seen a strong conversion from separate licenses to ReSharper Ultimate licenses as a result, especially on the personal side.

Another factor is the growing trend to integrate ReSharper Ultimate products more closely than before, in many respects. Starting from ReSharper 9.0, we have reworked ReSharper, dotCover, dotTrace, dotMemory and ReSharper C++ so that they could share a common set of assemblies while loaded in Visual Studio, which helped drastically reduce their cumulative memory footprint and in many cases actually made their concurrent usage in Visual Studio feasible. However, this change also meant there would only be a single set of compatible tools that you could use in Visual Studio alongside each other, which, in turn, prompted us to release updates to the entire ReSharper Ultimate family in a simultaneous manner.

Going forward, the plan is to make ReSharper Ultimate tools even more interconnected in ways that would move runtime analysis that dotTrace and dotMemory implement closer to static analysis that ReSharper excels at, and make profiling data more easily accessible in the code editor, during your day-to-day code maintenance activities.

What it means to you

First of all, if you’re only licensed to ReSharper and/or ReSharper C++, changes in the way we’re licensing dotCover, dotTrace and dotMemory don’t affect you at all.

If you are licensed to dotCover, dotTrace and/or dotMemory, then depending on the current set of licenses that you have, we hope that you can make an informed decision whether to convert to a ReSharper Ultimate subscription, and this post serves to help you with this.

We will consider 4 major cases, so that you need to only read through the section that reflects your particular situation and the changes your licensing and associated costs would undergo.

What is common for all cases:

  • Whenever we compare licensing costs before and after licensing changes, we assume regular renewals both with traditional licenses and with subscriptions. There are certainly other kinds of renew behavior with traditional licenses but they’re not directly comparable with subscriptions.
  • We start with a comparison table with Old-Cost vs. New-Cost rows, and Personal vs. Commercial columns broken into 1- and 3-year time spans, to help you consider the change in a long term. Whenever necessary, we’re presenting Min.-Max. price ranges instead of fixed prices.
  • We use special subscription pricing offered for all existing customers, which implies that every active license (or a license with an upgrade subscription that has expired less than a year ago) makes you eligible to receive 2 initial years of new subscription for the price of 1 year.
  • USD prices are used for simplicity.

Please take your time and review the scenarios suggested below:

Converting ReSharper Ultimate to subscription

If you already own a ReSharper Ultimate license, then you’re not dealing with separate licenses, and the only decision to make has to do with converting to the new subscription-based licensing model.

Also, there’s no way to compare ReSharper Ultimate subscription costs with renewal costs in the traditional licensing model: as ReSharper Ultimate is less than a year old, we simply have not had the opportunity to announce renewal pricing.

Personal licenses

Personal license holders are fine in terms of early cost even compared to the traditional new license pricing: upon conversion to the subscription model, a personal ReSharper Ultimate subscription is going to cost $89 for two initial years + $89 each subsequent year.

Commercial licenses

Converting commercial licenses is fairly straightforward as well: again, there’s nothing to compare to as we haven’t published renewal pricing for ReSharper Ultimate in the old licensing model but in the subscription-based world, a commercial ReSharper Ultimate license is going to cost $239 for two initial years + $239 each subsequent year.

Switching from combinations of licenses to .NET tools to a ReSharper Ultimate subscription

License maintenance costs in old and new licensing models (various combinations)

If you own licenses to a combination of ReSharper + dotCover, ReSharper + dotTrace, or dotTrace + dotMemory, yearly cost-wise a switch to subscriptions can result in anything from considerable savings to a slight price increase.

Personal licenses

If you’re a personal license holder, you’re saving anywhere from $49 to $99 by converting your license combo to a ReSharper Ultimate subscription that is, again, going to be worth $89 for two initial years + $89 each subsequent year.

Commercial licenses

For commercial licenses, a switch to ReSharper Ultimate subscriptions ($239 for two initial years + $239 for each subsequent year) is going to be cheaper compared to a combo of ReSharper + dotTrace or ReSharper + dotCover but a bit more expensive compared to a combo of dotTrace + dotMemory. If there’s any price increase however, it goes away in a 3-year span due to the special offer to existing customers.

If you’re a commercial customer and you’re looking to purchase ReSharper Ultimate licenses for more seats than you currently have, you can use the opportunity to “branch out” your existing licenses. The trick is that since special pricing for existing customers allows for the set of existing licenses, then if you have, say, a dotCover license and a ReSharper license, you can use them separately to switch to two ReSharper Ultimate subscriptions using the existing customer pricing, which would save you ~$470 on subscriptions in the span of 3 years.

Switching from dotTrace to ReSharper Ultimate

License maintenance costs in old and new licensing models (dotTrace)

Personal licenses

For personal license holders, even if you only own a license to dotTrace, converting to ReSharper Ultimate would cost you $10 a year less than renewing your dotTrace license each year on current terms.

Commercial licenses

For commercial licenses, switching from dotTrace-only license ($149 for current upgrade subscription renewal) to a ReSharper Ultimate subscription ($239 for two initial years + $239 for each subsequent year) is going to introduce a price increase although provided that you usually renew annually, you’re not going to feel it until the 4th year of your subscription.

If you’re concerned with long-term costs and you’re not ready to take advantage of all 5 commercial products made available by the ReSharper Ultimate license, then you might want to leave your current license and optionally purchase a traditional upgrade subscription renewal for one more year: those are still available before November 2.

Switching from dotCover or dotMemory to ReSharper Ultimate

License maintenance costs in old and new licensing models (dotCover or dotMemory)

If you only have a license to dotCover or dotMemory and want to keep these products updated going forward, this will introduce a price hit of a varying degree depending on your type of licensing. However, for some uses of dotCover, this can be mitigated by an upcoming free licensing mechanism (which is described later in this post).

Personal licenses

If you’re a personal customer and you only own a license to dotMemory or dotCover, a considerable price hit should be expected: while the current license terms allow for renewing dotCover or dotMemory at $49 each, a new ReSharper Ultimate subscription is $40 a year more expensive at $89.

When deciding how to proceed, keep in mind that you certainly have the option to just keep your existing license using the old licensing model without paying anything extra. Should you decide that this is the best way, then optionally, if your free upgrade period is coming (or has recently come) to a close, you can use the time before November 2 to renew your upgrade subscription period on old terms for one more year.

Commercial licenses

If you’re a commercial customer with only dotMemory or dotCover licenses, there’s quite a steep cost increase associated with moving to ReSharper Ultimate subscriptions: in the old licensing system, renewing a commercial dotCover license for a year is worth $99 and dotMemory $79 whereas a ReSharper Ultimate subscription for existing customers is going to be available for $239 for two initial years + $239 each subsequent year.

If you’re not ready to subscribe to ReSharper Ultimate, you can certainly keep your current licenses and optionally purchase an additional year of free upgrade subscription on old terms before November 2.

With commercial dotCover licenses however, if you’ve been maintaining them with a sole reason to use dotCover’s console runner on your CI servers, then the good news is that we’re going to introduce a free license to dotCover Command Line Tools (see more on this below.)

In other news: expect a free license to dotCover Command Line Tools

While dotCover is primarily intended to be used as a Visual Studio plugin for unit testing and code coverage, this is not its only use.

For example, dotCover has a console runner that is available out-of-the-box and for free with TeamCity. It is also possible to integrate it with other Continuous Integration servers in order to keep up to date with code coverage stats continuously. However in order to integrate dotCover console runner with Continuous Integration tools other than TeamCity, customers had to scratch their heads over the way this kind of usage was meant to be licensed, and usually ended up purchasing standard commercial licenses to dotCover.

We’d like to streamline the usage of dotCover console runner on external CI servers, and to do this, we’re going to provide a free license to dotCover Command Line Tools, similar to the license under which ReSharper Command Line Tools are available. We expect to finalize the license by November 2 so that you don’t have to subscribe to ReSharper Ultimate if the only usage you’re interested in is the usage of dotCover console runner with your CI server of choice.

What you need to do with regard to the licensing changes

1. First of all, we suggest that you take your time and consider all the pros and cons of new licensing opportunities for yourself or your company. For more information on the new subscription scheme in general, you can refer to the JetBrains Toolbox web site and JetBrains FAQ. If questions remain, please feel free to ask them here in this blog post or by contacting JetBrains sales.

2. Should you decide that converting to a ReSharper Ultimate subscription doesn’t suit you, you can safely stay with your current license. If you want to have another year of free upgrades within your existing license and without converting to a subscription, you can purchase an upgrade subscription renewal before November 2.

3. If you decide to convert to a ReSharper Ultimate subscription, you don’t need to do anything immediately; rather, you can proceed to converting your licenses to subscriptions on or after November 2.

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

ReSharper 10 EAP 4

This past weekend we have published a new ReSharper 10 EAP build, along with compatible builds of other ReSharper Ultimate tools. This time notable changes are available in ReSharper, ReSharper C++ and dotPeek. Let’s see exactly what the latest EAP has in store.


NUnit 3.0 Beta 4

As the new major version of NUnit is approaching release, we have laid the groundwork to support it in ReSharper test runner. We’ll definitely need to make more changes in order to support the release version of NUnit 3.0 but this far, the latest Beta 4 is supported.
ReSharper starts to support NUnit 3.0

Note that at this point, there’s a critical issue with NUnit 3.0 Beta 4 support in that you can’t run inherited tests in hierarchies of fixtures. We’re looking to fix this although we might need help from the NUnit team.

Device family-specific views in UWP applications

Universal Windows Platform enables using device family-specific XAML views to provide different UI for different types of devices. We have taught ReSharper to handle this technique with dedicated code inspections, quick-fixes and context actions.
Quick fixes to support device family-specific XAML views in UWP applications

Other changes

For your information, here’s the full list of fixes that made it into ReSharper 10 EAP 4.


Async Find Usages

dotPeek has introduced the non-modal, async Find Usages mechanic that has been available in ReSharper since version 9.1, which lets you keep on working with the decompiler while it executes a long usage search in the background.

More ways to view IL code

In other news, you can now opt to show IL code as comments to decompiled C# code, which effectively merges its default text viewer and the normally separate IL Viewer window, all in one view. This is not a default, and you should select Show IL code in comments in dotPeek options in order to turn this mode on.

IL code shown as comments in dotPeek

Finally, you can now make dotPeek display IL code not only for decompiled code but also for source code reproduced from symbol files.

ReSharper C++

In addition to a set of fixes, this ReSharper C++ EAP build includes a set of noteworthy changes:

  • Support for designated initializers defined in C99.
  • More ways to generate definitions inline via context actions and the Generate dialog.
  • A code inspection and a quick-fix to make functions static when possible.

What’s next?

We’re planning to release further EAP builds, hopefully more than once a week. However, very soon we’ll be wrapping up development so that we can meet the target release date for ReSharper 10 and other ReSharper Ultimate tools, which is set to November 2.

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

Taking Memory Snapshots by Condition in dotMemory 4.4

While dotMemory 4.4 is primarily focused on dotMemory Unit 2.0, it also brings a number of useful updates. One such improvement is the ability to take memory snapshots only when a certain condition occurs. The most common use case for this is taking a snapshot when the memory consumption in your application increases dramatically. As catching the moment manually (using the Get Snapshot button) may be quite tricky, dotMemory 4.4 allows you to automate the process.

All you need to do is set a particular condition, such as:

  • Memory consumption increase in MB
  • Memory consumption increase in %
  • Period of time in minutes (periodical taking of snapshots)

After the condition occurs, the snapshot will be collected automatically.

For example, let’s say we have a web application that allocates a huge amount of memory after some actions (but we’re not sure of their exact sequence). What is the root cause? Is this some ineffective algorithm or just IIS that reserves memory for hard times? In this case, the best solution is to attach dotMemory to the app pool that runs the application and take a memory snapshot when memory consumption surges. As we don’t want to spend all day waiting for this moment, we will add the condition on taking the snapshot.

  1. Attach dotMemory to the corresponding app pool (w3wp.exe process).
  2. As soon as the session starts, click Get Snapshot By Condition.
    Profiling session
  3. In the Get Snapshot by Condition window, specify the condition for taking a snapshot. In our case, we will take snapshot if memory consumption increases by 100 MB. The maximum number of snapshots that can be taken automatically is set by the Limit the max number of snapshots to parameter.
    Get Snapshot by Condition window
    That’s it! As soon as we click Start, dotMemory will track overall application memory usage. When it exceeds the current value (taken at the time of clicking Start) by 100 MB, dotMemory will take a snapshot, all on its own!

Getting snapshots by condition is enabled

Note that, as soon as the defined condition occurs, the memory consumption at that moment becomes the new baseline.

You can try this feature if you’re using dotMemory 4.4 or later (as a separate product or as part of ReSharper Ultimate).

Posted in How-To's | Tagged , | 1 Comment

Code Completion Improvements in ReSharper 9

ReSharper 9.x continues to build on the radical improvements in ReSharper 8 with even more completion features and enhancements to existing ones.

Here’s what we’ve got:

  • Completion filters let you take control of your search results if they get too big. The new completion filters let you fine-tune the set of results by showing a set of options below the completion list. These buttons can be toggled either using the shortcut keys or the mouse (left button adds the element, right button removes it):
    Code completion filters
    The behavior of completion filters is configurable in ReSharper’s options. You can choose whether to enable or disable filters, whether to show the filter bar, and whether filter state should persist between successive invocations. It is also possible to add custom filters which can take care of special circumstances, such as collisions between identically named APIs:
    Custom completion filter configuration
  • Sorting by relevance, which is a ReSharper 9.1 feature, ensures that the set of completion items you are shown have the most relevant items listed first. Also, selection no longer jumps between items while populating the completion list.
  • Fuzzy matching ensures that, even if you make a mistake in an identifier, code completion results will still show the right item if it looks to be similar. Here’s an example:
    Fuzzy matching in code completion
  • Combo returns are a novel feature useful for situations where you have a method that has to do either a return or a yield return. When using smart completion in a return statement, ReSharper filters the list to only show the types that match the return value:
    Combo returns
    Return completion also detects the use of an enum member that is being returned:
    Enum members in return completion
  • Parameter info now includes ReSharper’s annotations:
    Annotations in Parameter Info
    This new behavior is configurable: you can elect to show all annotations, only NotNull/CanBeNull, or hide them altogether. You can also now limit the number of signatures that are shown in the Parameter Info list:
    Parameter Info configuration
  • Double completion improvements (read this for more info on double completion) now show potentially overridable methods after override, static members in non-static context, instance members in a static context, sealed types after typing : in a class declaration, abstract types after typing new, and non-partial classes after typing partial class.
  • Smart completion for strings determines situations where a parameter that takes a string actually takes a specific range of values available elsewhere. For example, here is how ReSharper shows smart completion for a WebRequest.Method property:
    Smart completion for strings

Finally, as always, we’ve made performance improvements to the way code completion works. The completion mechanism was partially rewritten so as to make the lookup items lazy, and to ensure that only the items in the current view are rendered. This makes this whole thing faster, just so you know.


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

Analyzing slow HTTP requests with dotTrace

Modern applications are becoming more complex and use an increasing number of subsystems such as databases, web services, third-party frameworks, and so on. When your application suddenly starts performing slower, it’s not always easy to understand which subsystem is to blame. This is when profiling can come to your rescue, and even then it may be tricky. Imagine that the calls in your application are evenly distributed among multiple subsystems. If your profiler doesn’t aggregate calls by particular subsystems, finding a performance flaw will become a headache. That’s why we always say that the more performance aspects and subsystems your profiler supports, the better.

A while ago we introduced support for analyzing SQL queries in dotTrace 6.1. Now the time has come for the next data filter: dotTrace 6.2 supports filtering out HTTP requests. When analyzing a snapshot, you can get the exact data on how a particular HTTP request is processed. For example, to process a request, a web application may access databases, communicate with a number of external resources via their APIs, process data, and so on. Performance flaws at any of these steps may result in a slow overall response of your application. The Incoming HTTP Requests filter will help you determine the exact cause and find the methods that run slowly.

Important notes:

  • HTTP requests can be profiled only in the Timeline profiling mode.
  • Only incoming HTTP requests are shown. More specifically, Timeline Viewer filters out time intervals between a server receiving a request and sending a response.

Let’s take a more detailed look at how this works.

Let’s say, we’ve updated a web application and now it works slower than before. Our workflow is pretty straightforward: we use Timeline profiling to reproduce the slowdown and take a snapshot, and then we open the collected snapshot in Timeline Viewer.

If we use dotTrace 6.2, we see that Interval Filters now has a new filter, Incoming HTTP Requests:

Interval Filters

In our example, the application processes HTTP requests for a long 31 seconds. Let’s turn on the Incoming HTTP Requests filter to see what’s happening:

Sub-filters for HTTP requests

After we turn on the Incoming HTTP Requests filter, two more sub-filters appear: URL and Method. The URL sub-filter shows the time distribution between requests to particular URLs. The Method sub-filter allows us to understand how the request times are distributed among particular HTTP methods.

If the URLs do not fit the URL filter area, consider opening them in a separate Incoming HTTP Requests window.

HTTP requests window

As we can see, our application spent most of the time processing requests to the URL /Employee/SearchByName. To find out what exact methods were called, we should apply the filter by this URL. Double-click on the URL, and now all other filters show data only for the time intervals where the request to /Employee/SearchByName was processed.

The Call Stack | Top Methods window shows that most of the processing time was spent in a single method:

Call stack

We click on this method to take a look at its source code in the Source View window. In our case, the web application spends most of the time in the ASP-generated Execute() method for the index page. This lets us assume that the application probably lags because of the large amount of data it has to display, and limiting the number of entries in a page can contribute to solving the problem.

Call Tree and Source View

We hope you find this new feature useful when developing and maintaining web applications. To try it on your own, download dotTrace 6.2 or later.

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

ReSharper 10 EAP 2

We have launched EAP for ReSharper 10 about a week ago with a set of fixes and improvements to JavaScript and TypeScript. We hinted that we had more to offer as soon as we merge the new material. Today is the day when we start delivering. ReSharper 10 EAP 2 adds considerable changes in ReSharper itself, as well as in two other ReSharper Ultimate tools: ReSharper C++ and dotPeek. Below is the list of highlights:


Out-of-the-box postfix templates

Do you know postfix templates? There’s a ReSharper plugin started over 2 years ago that has since garnered quite a lot of following. The idea has even been implemented in IntelliJ IDEA and its derivative products and made available out of the box. In ReSharper 10, in order to close the circle, we’re including postfix templates into core ReSharper, and this is already available in ReSharper 10 EAP 2.

From now on, without installing any plugins, you can enjoy postfix templates in C#. For example, you can start with an expression and proceed to wrap it in an if statement to check whether it returns true.

More than that, if you’re dealing with null checks on a regular basis, use .null and .notnull postfix templates:
ReSharper's postfix template to check if something is not null (before expanding)
This will both check if the selected entity is not null and wrap it in an if statement:
ReSharper's postfix template to check if something is not null (after expanding)
Need to throw an exception if the condition is met? Enter the exception class name, then a dot, and look what we’ve got here:
ReSharper's postfix template to throw an exception (before expanding)
After selecting the .throw template, you have the complete throw statement, and the caret in place to enter arguments:
ReSharper's postfix template to throw an exception (after expanding)

Usage-aware Go to declaration

In other news, ReSharper 10 EAP 2 extends the functionality of Go to declaration (as well as Ctrl+click) so that you can also use the shortcut to look up usages.

In the easiest case where you have one declaration and one usage, you can use Go to declaration to simply switch between them: you’re simply enabled to use a single shortcut instead of two different shortcuts.

If you have multiple usage of a symbol, here’s what you can do:

  • Invoking Go to declaration on a usage for the first time gets you to the declaration as you would expect.
  • Invoking Go to declaration for the second time (when already on the declaration) gets you back to the usage where you came from.
  • Subsequent Go to declaration hits 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 feel like doing this.
    A pane that shows found usages for the extended Go to Declaration

Needless to say, at any point you can hit Esc to revert to the traditional, non-usage-aware Go to declaration.

Further fixes

We’ve fixed more red code in Xamarin.Forms projects and elsewhere. Other fixes are scattered across TypeScript support, Feedback Center, code completion and Code Cleanup, among other subsystems. Here’s the (hopefully) full list of fixes in ReSharper 10 EAP 2 if you’re interested in details.

ReSharper C++

The ReSharper C++ team has basically merged everything they’ve worked for since mid August. There are about 90 issues closed during the time span, and the list is highlighted by the following:

  • A new context action to create derived class when standing on a class declaration:
    Create derived class action in ReSharper C++
  • New context actions to replace decltype with the underlying type, as well as to substitute a template type alias:
    Substitute template type alias
  • A new gutter icon (in addition to a code inspection and a quick-fix) that displays whenever ReSharper C++ detects that one local declaration hides another local declaration:
    Declaration hides previous local declaration

Other notable changes include a more elaborate way to determine that a function can be made const, support for functions marked with [[noreturn]] and __declspec(noreturn) attributes, a generate action that creates Google Mock stubs, and a way to navigate from a function declaration’s parameter to the corresponding parameter in the function’s definition.


The dotPeek team has implemented one of the most anticipated features: you can now navigate to IL code from any point in the C# decompiled code viewer:
Navigate to IL code viewer in dotPeek
IL code is shown in a separate tool window that is synchronized with the main code viewer:
dotPeek IL viewer tool window

IL code support is not yet implemented in ReSharper but we’ll be working on that as well.

In another considerable change, dotPeek now supports the same set of color themes as Visual Studio does: for example, you can select Blue or Dark theme, or choose to synchronize your color scheme preference with Visual Studio settings.
Dark theme in dotPeek

What’s next?

If the changes described above are relevant to you, you’re more than welcome to download ReSharper 10 EAP 2.

We have more significant changes waiting in line to be made public in further EAP builds. Stay tuned.

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

Memory Testing on a CI Server. dotMemory Unit Standalone Launcher

After we announced the dotMemory Unit framework, the most frequently asked question was, “When will the standalone launcher for CI be available?” Finally, the time has come! Along with dotMemory 4.4, we have also released dotMemory Unit 2.0 which contains not only a lot of improvements but also the dotMemoryUnit.exe tool.

The tool (distributed as a zip archive*) works as a mediator: it runs a particular standalone unit test runner under a profiler and provides support for dotMemory Unit calls in the running tests.

*Important! If your domain policy is to treat files from the Internet as unsafe, don’t forget to unblock the zip file by clicking the Unblock button in file properties.

For example, this is how you can run NUnit tests from some MainTests.dll file:
-targetExecutable="C:\NUnit 2.6.4\bin\nunit-console.exe"
-returnTargetExitCode --"E:\MyProject\bin\Release\MainTests.dll"


  • -targetExecutable is the path to the unit test runner that will run tests.
  • -returnTargetExitCode makes the launcher return the unit test runner’s exit code. This is important for CI as the build step must fail if any memory tests fail (test runners return a nonzero exit code in this case).
  • The parameters passed after the double dash (--) are unit test runner arguments (in our case it’s a path to the dll with tests).

Now, it’s easier than ever to make memory tests a part of your continuous integration builds. Simply add the command shown above as a build step on your CI server, and it will run your tests with the dotMemory Unit support.

For example, this is how the build log of a failed step looks like in TeamCity:

dotMemory Unit launcher output

However, if you’re a TeamCity user, we can offer a much more convenient solution.

Integration with TeamCity

Along with dotMemory Unit 2.0, we release the plugin for TeamCity that adds support for dotMemory Unit to all .NET test runner types. Let’s take a more detailed look at how this works.

TIP! If you want to take a look at a working example, here is a sample build project on our public TeamCity server. Project build configuration is available at this link.

  1. On your TeamCity server, copy (get the latest version from Artifacts on JetBrains build server) to the plugins directory located in your TeamCity data directory.
  2. Restart the TeamCity Server service.
    Now, all .NET test runners in TeamCity provide support for dotMemory Unit.
  3. As the dotMemory Unit standalone launcher is required for the plugin to work, you should provide it to your build agent. There are two ways to do this:
    • Download and unzip the launcher to any directory on a TeamCity build agent. Don’t forget to Unblock the zip!
    • [Recommended] Use the launcher from the dotMemory Unit NuGet package referenced by your project.
      Note that if you omit binaries from the source control repository, you can use TeamCity’s NuGet Installer runner type. It will perform NuGet Package Restore before the build. All you need is to add the NuGet Installer “build step” and specify the path to your solution.
      NuGet Installer Step
  4. Now, update the step used to run tests in your build configuration. Open the corresponding build step in your build configuration:
    TeamCity Unit Test Build Step
  5. Note that after we installed the dotMemoryUnit plugin, this build step now additionally contains the JetBrains dotMemory Unit section. Here you should:
    • Turn on Run build step under JetBrains dotMemory Unit.
    • Specify the path to the dotMemory Unit standalone launcher directory in Path to dotMemory Unit. Note that as we decided to use the launcher from the NuGet referenced by our project (see step 3), we specify the path relative to the project checkout directory.
    • In Memory snapshots artifacts path, specify a path to the directory (relative to the build artifacts directory) where dotMemory Unit will store snapshots in case memory test(s) fail.

    dotMemory Unit support

  6. Save the configuration.

Done! Now, this build step supports tests that use dotMemory Unit.

From the point of the end-user, nothing has changed. If you run the configuration and any of the memory tests fails, the results will be shown in the overview:
TeamCity failed build overview

The Tests tab will show you the exact tests that have failed. For example, here the reason had to do with the amount of memory traffic:TeamCity Tests Tab

Click on a failed test to see exactly was has gone wrong:
TeamCity test result

Now, you can investigate the issue more thoroughly by analyzing a memory snapshot that is saved in build artifacts:

Build Artifacts - Memory Snapshot

Note that to open memory snapshots, you will need a standalone dotMemory (or ReSharper Ultimate) installation.

Snapshot in dotMemory

Additional Benefits

If you’ve used dotMemory Unit before, you probably know that it required ReSharper unit test runner to work. Since v2.0, you can also run tests via dotMemory Unit’s standalone launcher and the list of supported unit testing frameworks has expanded to include:

  • MSTest*
  • NUnit*
  • XUnit
  • MBUnit
  • csUnit

*Can also be run from Visual Studio with ReSharper

Nevertheless, if your unit testing framework is missing from this list (e.g., MSpec), you can still use it with dotMemory Unit.

All you need to do is tell dotMemory Unit where your test method starts and where it ends. This is done with two methods: DotMemoryUnitController.TestStart() and DotMemoryUnitController.TestEnd().

We recommend that you create an IDisposable class that uses these methods, and then wrap the code in your tests with the using statement that creates an instance of this class:

That’s it! Now you can run tests wrapped in this way using dotMemory Unit standalone launcher or Visual Studio with ReSharper (in case it has the extension for the unit testing framework you use). Simply copy & paste the code above and reuse it in your project. You can also find this code on github.

With this new feature, dotMemory Unit becomes very flexible: you can use it not only to add support for a unit testing framework, but also to extend and adapt dotMemory Unit to your specific needs. For example, see how we added support for MSpec.

Thanks for reading! As always we recommend that you try dotMemory Unit on your own. If you’re already using it, then probably automating your tests on a CI server is the next logical step.

Posted in dotMemory Tips&Tricks, How-To's | Tagged , , , , | 2 Comments

Meanwhile… ReSharper 10 EAP kicks off

We have just opened Early Access Program for ReSharper 10, which means you can start using the latest development builds of ReSharper and its sibling tools: ReSharper C++, dotTrace, dotCover, dotPeek and dotMemory.

We should note that we’re not starting with a bang this time: a lot of changes, large and small, that we expect to make part of this release are not merged in yet, and we’ll be making more announcements as they are introduced in the EAP. In addition, as of the inaugural EAP build, noticeable changes have only occurred in the mainline ReSharper, and all the other products are only available for compatibility purposes.

That said, here’s a couple of reasons why you might want to try ReSharper 10 EAP right now:

  • Initial support for JSX syntax is now available in .jsx files order to streamline using React in ASP.NET applications. Code completion, all ReSharper’s regular context actions for HTML and JavaScript, navigation to declarations and search for usages, as well as a couple of refactorings are already available:
    Refactoring options as part of JSX support in ReSharper
  • JavaScript regular expressions that were originally supported in ReSharper 9.2 are now covered in more detail. Specifically, regular expressions are now recognized in RegExp constructors and methods, as well as in String object methods (match(), search(), replace(), split()), in addition to regular expression literals. Also, Make regular expression and Remove regular expression context actions are now available in JavaScript.
    JavaScript regular expressions via RegExp objects
  • TypeScript 1.6 support has gotten stronger with the addition of intersection types (RSRP-445826).
  • Less red code in C#. We’ve fixed a number of scenarios where ReSharper couldn’t resolve perfectly valid code, such as extension methods (RSRP-447688), System references in Xamarin.Forms projects (RSRP-447755), and await statements in Universal Windows Platform applications (RSRP-445975). Web sites in Visual Studio 2015 have received their fair share of red code fixes as well.
  • Fixes in ReSharper Command Line Tools, mostly related to analyzing WPF applications (RSRP-447361) and making sure that InspectCode can be successfully launched on funny file paths (RSRP-447873).
  • IntelliSense fixes related to formatting on completion before attribute (RSRP-437539), smart completion formerly leading to Visual Studio errors (RSRP-445914), and performance issues when collecting extension methods to show in completion (RSRP-447262).
  • An important unit testing regression has been fixed, and parent nodes in Unit Test Sessions tool window again show exactly how many child tests have failed (RSRP-442851).

If you find the changes outlined above relevant to your work, please download ReSharper 10 EAP, and expect more changes soon: both in ReSharper itself and in other products that are part of the ReSharper Ultimate family.

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