Performance profiling in Continuous Integration: an updated dotTrace plugin to TeamCity

A while ago, we introduced the dotTrace plugin to TeamCity. It helps you prevent application performance regression by profiling integration tests on a TeamCity server.

Now we’re releasing the next version of this plugin that brings some significant improvements. Before we move on to the details, let’s recall how the plugin is used for tracking performance in CI builds:

  1. Write an integration test that runs some performance-critical functionality in your application.
  2. In the plugin, set a performance threshold for this test, which is the execution time value in ms or value taken from previous successful builds. Now, if the test exceeds its threshold, the plugin will fail the build and save the collected performance snapshot to build artifacts.
  3. Open the snapshot in dotTrace and find the exact cause of the performance issue.

This simplified workflow description is missing one obvious yet very important step: plugin configuration. The initial plugin required a number of preparatory steps on the build agent side: installing the console unit test runner and creating a rather complex XML configuration file (containing various profiling options, like profiling target, type, and so on). The new release addresses this issue: you no longer need to install the runner or create the configuration file. The trick is that the plugin is now made a part of unit testing build steps. Thus, after installing the plugin, all these build steps (Visual Studio Tests, NUnit, MSpec, and others) get the additional option Run build step under dotTrace profiler.

Plugin integration

Moving profiling under unit testing build steps is also beneficial in one more way. From now on, when the plugin is enabled, you can not only check performance of tests but also track test results as usual (it’s still a “normal” unit testing build step).

Below, we’ll provide the detailed plugin usage example that you can use as a step-by-step guidance for the new dotTrace Plugin for TeamCity.

1. Install the plugin and dotTrace Console Profiler

IMPORTANT! If you use the previous plugin version, uninstall it before proceeding to this step.

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

2. Write an integration test

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

* The plugin supports all TeamCity .NET unit test runners, but we will use NUnit in our example.

3. Create a build configuration

The next step is to create a build configuration dedicated to performance testing in TeamCity.

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

Suppose we already have a project called My Project. Let’s add to that project a configuration consisting of two steps: building the application and running performance tests. To save time, let’s proceed right to configuring the second build step.

  1. In build configuration settings, go to Build Steps and click Add build step.
    Build configuration
  2. In Runner type, select NUnit. (If you use a different testing framework, you would select the appropriate runner type, e.g. MSTest or Visual Studio Tests.)
  3. Set options for NUnit. The main one here is Run tests from — the relative path to the DLL with tests.
  4. Select Run build step under dotTrace profiler.
  5. Set the following plugin options and then click Save:
    • Path to dotTrace ConsoleProfiler.exe: the path to the directory that you have unzipped dotTrace Command Line Tools into. In our example, it’s C:\Console Profiler
    • Measure type: the type of profiling you want to use. We strongly recommend that you use only the Sampling type as it gives the most realistic time values. Note that the plugin does not support Timeline profiling.
    • Performance snapshot artifacts path: set the path relative to the artifacts folder for storing the collected performance snapshot. Keep in mind that, depending on application complexity, the snapshot may take up hundreds of MB of disk space. We recommend updating your artifact cleanup policy so that after some time TeamCity would delete the snapshot folder from artifacts.
    • Threshold values : specify the list of methods whose performance you want to check. The pattern is Namespace.Class.Method TotalTime OwnTime, where
      • TotalTime is the method’s execution time, including its own time and the time of the method’s call subtree, in milliseconds;
      • OwnTime is the method’s own execution time, in milliseconds.

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

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

dotTrace build step configuration

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

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

4. Set a failure condition

If we want the build step to fail when a test exceeds its performance threshold, we should set a failure condition.

  1. In Build Configuration Settings, go to Failure Conditions.
  2. In Fail build if, select an error message is logged by build runner.

Build step failure condition

5. Run the build

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

  1. Run the build.
    Build step first runAs TeamCity had no data on the methods’ execution times before the first build, the build passes successfully (the expected values equal 0).
  2. Suppose now that someone has edited the Goo() method and made it slower. We’ll emulate this using Thread.Sleep(200) and re-run the build. Now, the test still passes, but the build fails due to an error:
    Build step second run
    If we now click on the build, we’ll see the following build results:
    Methods that exceeded performance thresholds
    As we instructed the plugin to save a performance snapshot, it has stored the archive with the snapshot in the artifacts Snapshots folder:
    Performance snapshot in build artifacts
    Note that the snapshot consists of a number of files. Now, we can analyze the snapshot and find the exact cause of the performance flaw:
    Snapshot opened in dotTrace
  3. As all values are reported as TeamCity statistic values, so you can build trend graphs for the measured time values if you like. To do this, open the Parameters tab of any build and switch to Reported statistic values:
    Reported statistic valuesClick View trend for a particular parameter to see its diagram of changes:
    Statistic value trend

Summary

As this post has illustrated, the updated dotTrace plugin for TeamCity no longer requires complex configuration, which makes it easier to use. To check it out on your own, please download the plugin (remember to use guest / guest credentials to download). As always, we’d be happy to hear any feedback from you. Feel free to ask any questions in the comments to this post.

Profile with pleasure!

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

ReSharper Ultimate 10.1 EAP 2

The first EAP build of ReSharper Ultimate 10.1 introduced a massive list of new features and improvements, which spanned two blog posts. And here we are today with another EAP build, which you can give a try right away.

ReSharper

The most notable changes in ReSharper were merged this time by the JavaScript/TypeScript team. Among these changes are improvements in performance of caches and File Structure view, reworked Rename refactoring (which can now rename files corresponding to TypeScript types), as well as support for TypeScript implementations and overrides in Find Usages.

TypeScript keywords var, let, and const are now resolved according to the types they reference. This means that you can Ctrl-click these keywords to go the corresponding type declarations or just hover the mouse over to learn what a keyword refers to.

ReSharper support for var, let, const in TypeScript

JavaScript/TypeScript formatter settings became much more granular. You can now specify the right margin for your code and define whether and how various code constructs should be wrapped. For example, you can specify where to place dots in multi-line chained method calls or you can opt for a ‘comma-first’ style for lists, object literals and function calls.

New features in JavaScript and TypeScript formatter

ReSharper 10.1 also brings initial support for Node.js. All ReSharper goodies you are well familiar with, like completion, code inspections, quick-fixes, and navigation features are now available for Node.js. However, we badly need your feedback on how ReSharper handles different things in your specific scenarios with Node.js.

ReSharper support for Node.js

dotPeek

For a long time, opening .nupkg files from disk was the only way to load assemblies from NuGet packages. In this dotPeek EAP build, you can try two more ways: find and load NuGet packages (and their dependencies if necessary) from any online package source, or load packages listed in a packages.config file in your Visual Studio project.

dotPeek: Loading assemblies from NuGet packages

Another handy improvement is that dotPeek automatically highlights usages of the symbol under the caret. We hope now that obfuscated identifiers will not get lost as easily in decompiled code.

dotPeek: highlighting symbol usages

dotMemory

All your navigation history through dotMemory profiling results is now recorded and you can quickly return to any view or diagram that you once opened using the browser-style Back and Forward buttons.

Back and Forward buttons for dotMemory

dotCover

Coverage filters, which let you ignore specific parts of your code when calculating coverage, are now supported in Continuous Testing.

Give it a try

Interested in the improvements described above? Please go on and download ReSharper Ultimate 10.1 EAP.

If you are experiencing any issues with the EAP, please report them to issue trackers of affected products: ReSharper, ReSharper C++, dotTrace, dotCover, dotMemory, dotPeek.

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

Project Rider: subscribe to receive early builds as soon as they are ready

Remember Project Rider, that funky mix of ReSharper and the IntelliJ platform that makes up a new cross-platform C# IDE?

JetBrains Rider: text editor and quick-fixes

We’re actively working to start delivering builds that are good enough to be used outside JetBrains.

Meanwhile, we have just opened a form for you to subscribe to take part in Project Rider Early Access Program. To everyone who subscribes, we will be sending links to Project Rider builds as soon as they are ready.

Subscribe and hold on!

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

ReSharper Ultimate 10.1 EAP Build 1 (Part 2)

The scope of improvements in the recently launched ReSharper Ultimate 10.1 EAP is so huge that the communications just don’t catch up with the development team anymore.

In the first part of an overview of the latest ReSharper Ultimate, we talked about an array of new context actions, refactorings, code inspections and quick-fixes.

This part 2 is less centered around C# support and lists more prominent improvements across languages supported by ReSharper, as well as considerable updates to other ReSharper Ultimate products: ReSharper C++, dotTrace and dotPeek.

ReSharper (continued)

Smart Paste

Smart Paste is a new feature that ensures the right escaping in string literals that you copy/paste around your code.

For example, you can copy a piece of text or XML that contains double quotes, paste it into a string literal in C#, and have ReSharper automatically escape all the quotes.

Smart-pasting XML into a C# string literal

This also works when you’re pasting a piece of C# code into an XML doc tag: Smart Paste will escape any generics and lambda syntax, as well as logical operators and anything else that is fine in C# but not allowed in XML values.

Other things that ReSharper can escape for you include file paths and line breaks.

The feature works in C#, VB.NET, JavaScript, XML, XAML and HTML files, making sure to respect the different ways of escaping illegal characters that are used in different contexts.

Initial support for JSON and JSON schemas

ReSharper 10.1 is expanding its technology reach by supporting JSON files and schemas in all supported versions of Visual Studio (2010-2015).

JSON and JSON schema support currently ranges from things as basic as syntax highlighting in older Visual Studio versions, to more sophisticated features like formatting and rearranging (for example, you can move object properties or arbitrary selections around), code inspections and quick-fixes, as well as code completion that is aware of schemas, paths, regular expressions and packages.

Regexp completion in JSON schema

JavaScript and TypeScript support evolves

ReSharper 10.1 brings initial support for experimental JavaScript syntax constructs that are projected to be part of ECMAScript 7. These include comprehensions, decorators, class properties, exponentiation operator, rest and spread properties for object literals.

In terms of TypeScript, ReSharper 10.1 EAP is highlighted by:

  • Support for TypeScript 1.7 that is (hopefully) complete
  • Experimental support for TypeScript 1.8 including string literal types

Other changes

Other notable changes in ReSharper 10.1 EAP 1 include:

  • Run configurations that are extended so that you can now attach the debugger to a running configuration
  • New code style settings and inspections to enforce style for braces and attribute sections
  • A quick-fix to convert a part of a loop to LINQ is now disabled by default (as it rarely produces a readable result), and a quick-fix to convert the full loop to a LINQ expression is downgraded to a hint
  • Correct detection of C# language level in .cshtml files
  • A new context action to add braces around switch case statements
  • Various fixes to existing quick-fixes such as “Encapsulate field” and “Change instantiated type”

Here’s the (presumably) full list of fixes in ReSharper 10.1 EAP 1.

ReSharper C++

Similar to the mainline ReSharper, ReSharper C++ 10.1 EAP introduces a substantial set of new context actions and quick-fixes. In addition, it adds To-do Explorer, improves the code generation subsystem, and supports more C++ language features.

To-do Explorer

ReSharper C++ 10.1 introduces the long-awaited navigation view: the To-do Explorer, which lets you view, group and filter comments that contain one of the 3 default to-do patterns (Bug, Todo and Not Implemented) and any custom patterns that you might want to set up.

Todo Explorer in ReSharper C++

If you use the full ReSharper Ultimate license and you have a multilingual solution, the To-do Explorer will gather to-do items from all supported languages: C#, VB.NET, C++, JavaScript, XAML, HTML etc.

An array of new context actions and quick-fixes

In most cases whenever there’s a code inspection, one or several quick-fixes should be available to alleviate a detected problem. With that in mind, ReSharper C++ 10.1 adds quick-fixes to some of its existing code inspections. Examples include:

  • “Create and initialize field from constructor parameter” is now available as a quick-fix to a code inspection that detects an unused constructor parameter:
    Quick-fix to create and initialize field from constructor parameter in C++
  • Whenever ReSharper C++ reports possible unintended object slicing, it now suggests a quick-fix to add an explicit cast.
  • If the type of a value that is actually returned doesn’t match the return type of a function, ReSharper C++ will suggest a quick-fix to change the return type:
    Quick-fix to change function return type in C++
  • If you are trying to assign to a read-only member, ReSharper C++ will now suggest to make the data member involved mutable:
    Quick-fix to make data member mutable in C++
  • If a base class or its function receives a final specifier, ReSharper C++ will put error highlighting over its overriding classes or functions and provide quick-fixes to remove the specifier
  • For any empty declaration that ReSharper C++ encounters, it will suggest a quick-fix to get rid of it

Other changes

Other notable changes in ReSharper C++ 10.1 EAP 1 include:

  • Rename refactoring can now rename files in addition to code symbols
  • The list of supported C++ language features is extended with generalized lambda captures (C++ 14) and exception specifications
  • The Generate stream operations action available via Alt+Ins can now generate stubs for Boost.Serialization functions: save(), load() and serialize()
  • Generate relational operators can now optionally use std::tie
  • Formatting options are now taken into account when generating code
  • All ReSharper C++ actions are banned from changing library headers
  • Code completion in C++ has undergone a massive bugfix, totaling around 50 resolved issues

Here’s the full list of fixes in ReSharper C++ 10.1 EAP 1.

dotPeek

Extension methods rendered as instance methods

For years, dotPeek has displayed extension methods as static method calls, often complexified with a legion of casts, all of which made extension methods hard to follow in decompiled code.

This update finally learns to show extension methods being called like instance methods, which makes for much more readable code.

Extension methods in decompiled code

You’ll notice from the screenshot above that dotPeek will only show extension methods as an instance method call if it is valid to do so. That is, QueryExtensions.SortBy is shown as an instance method call, but Queryable.Take and Queryable.Skip are shown as static methods, because there are other Take and Skip methods in scope that would make showing these as instance calls ambiguous.

As this change belongs to the decompiler core, it should apply in ReSharper’s integrated decompilation functionality as well.

dotTrace

Thread diagram in Visual Studio

dotTrace integrated in Visual Studio becomes a fully functional Timeline Viewer that allows you to perform detailed analysis of timeline performance snapshots right in Visual Studio.

Threads diagram, a part of dotTrace Performance Profiler integrated in Visual Studio

Before dotTrace 10.1, the main drawback of the integrated viewer compared to its standalone counterpart was the absence of the Threads diagram. This update removes the drawback: the integrated viewer gets exactly the same diagram, which you can now use to select threads, time range, and of course, view thread activity and filtered time intervals.

Other changes

dotTrace console utilities also get their portion of improvements. The reporter.exe tool used to get performance data from snapshots (e.g., for profiling automation and CI) now puts additional data in its XML reports. If you build a report with the /add_process_info option switched on, the report will include a path to the executable of the process that was profiled. This can be extremely helpful when profiling applications with multiple child processes.

There is also a number of minor improvements, such as updated colors in Timeline Viewer tables (it’s now easier to distinguish between table item states), and a more convenient grouping of snapshots in dotTrace Home.

dotMemory, dotCover

As of ReSharper Ultimate 10.1 EAP build 1, dotMemory and dotCover don’t include any significant updates apart from bug fixes.

Wrapping it up

Please download ReSharper Ultimate 10.1 EAP.

Experiencing issues with the EAP? Please report them to issue trackers of affected products. Here are links to issue trackers that you can use to report or track issues: ReSharper, ReSharper C++, dotTrace, dotCover, dotMemory, dotPeek.

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

ReSharper Ultimate 10.1 EAP Build 1 (Part 1)

Have you felt like it’s been all about Project Rider lately? Guess what, it hasn’t. We’ve been busy updating ReSharper Ultimate tools, and yesterday opened a new Early Access Program: ReSharper Ultimate 10.1 EAP 1 is now available for download.

This initial ReSharper Ultimate 10.1 EAP build accumulates a lot of changes across ReSharper and ReSharper C++; a few notable improvements in dotPeek and dotTrace; while changes in dotMemory and dotCover are so far limited to bug fixing and cosmetics.

Well, in fact, there are so many changes that this post only unveils those of them that relate to C# support in mainline ReSharper. Changes in support for other languages, as well as improvements to ReSharper C++, dotPeek and dotTrace will be described in a separate post later this week.

Anyway, please read on.

ReSharper

New context actions around strings

C# 6.0 as a whole and string interpolation in particular has been supported for a while, and this update adds a bunch of actions that help you switch between different ways of handling strings, such as interpolation, concatenation, and string.Format(), and makes sure all this is just an Alt+Enter away.

For instance, there’s now a context action to rewrite a string interpolation expression as a string.Format() call:
Convert to string.Format() call

Fancy string interpolation over concatenation? Alt+Enter will save you the effort of finding the right keys on your keyboard:
Convert string concatenation to interpolation

Gone way overboard experimenting with C# 6.0 features? No problem, ReSharper will detect whenever there’s nested string interpolation that should can be simplified:
Inline nested string interpolation

In some contexts, you just don’t need to use verbatim characters to differentiate identifiers from keywords. ReSharper can now point you at this kind of redundancy, and help you get rid of it locally or in a wider scope:
Remove redundant verbatim character

Other new actions around strings help:

  • Make a string equality check case-insensitive
  • Insert new arguments into string interpolation expressions
  • Use string interpolation expressions with various logger frameworks

New context actions to check argument values

Another group of context actions serves to generate checks upon method parameters based on their types:

  • For string parameters, ReSharper helps generate checks not only for nullness but for empty and whitespace strings
  • For numeric parameters such as int, double or decimal, ReSharper can write a check that ensures that only non-negative values are passed
  • For enum parameters, ReSharper generates a check that makes sure that an enum value being passed is in fact defined in the appropriate enum declaration, therefore guarding against ill-fated casts
  • Finally, for collection parameters, ReSharper helps set up a check against empty collections

Context actions to check parameter values

WCF-specific context actions, inspections and quick-fixes

Something clicked, and we’ve come up with a few inspections and actions that address some of the most common issues in WCF service development.

For example, whenever you have a WCF service method that is marked as [OperationContract(IsOneWay=true)] but it returns anything other than void or Task, ReSharper will spot this and suggest a fix to prevent a runtime error: you can either change return type to void or make the method two-way:

WCF quick-fix for a one-way operation that returns a non-Task type

If you have a [ServiceContract]-annotated interface that doesn’t have a single [OperationContract] member, then there’s something clearly going wrong: ReSharper will spot this and provide a quick-fix to annotate all members of the interface with [OperationContract].

Likewise, if you have methods marked as [OperationContract] in an interface that doesn’t have a [ServiceContract] annotation, ReSharper will spot this and suggest two options to resolve the issue:

WCF: containing type not marked as ServiceContract

Finally, there are new context actions to help you annotate all members in a [DataContract] type with either [DataMember] or [EnumMember] attributes. The longer your [DataContract] types are, the more you’re likely to appreciate this context action:

Context action to annotate WCF DataContract members with EnumMember

More new context actions and quick-fixes

There’s an assortment of new context actions and quick-fixes that can’t be classified as easily. These include:

  • A pair of context actions, one of which comments out a selection (effectively serving as an Alt+Enter equivalent of dedicated ReSharper shortcuts for commenting code), and the other uncomments whatever comment is under caret
  • A context action to delegate implementation of a non-implemented interface to a new field of the corresponding type
  • A pair of context actions to split or join attribute sections
    Context actions to split or join attributes
  • A context action to create another part of a partial type
  • A context action to add braces around switch case statements

Invert Boolean Member refactoring

When you modify a member that returns a boolean so that it gets an opposite meaning (say, refactor a method called IsNotAvailable() to IsAvailable()), you likely want to invert the value that it returns, and update other members that receive values from it.

This is what the new Invert Boolean Member refactoring can do for you. For example, by invoking it on a method, you can choose to rename the method and either invert values inside the method, and/or invert usages of the method.

Invert Boolean refactoring

The refactoring can be invoked on a method, property, local variable or a parameter.

More ReSharper improvements; changes to ReSharper C++, dotTrace and dotPeek…

…will be described in a follow-up post shortly.

What’s next?

Please download ReSharper Ultimate 10.1 EAP and make sure to put it to good use.

If you are experiencing issues with the EAP, please report them to issue trackers of affected products. Links to issue trackers that you can use to report or track issues are as follows: ReSharper, ReSharper C++, dotTrace, dotCover, dotMemory, dotPeek.

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

Code Style Settings in ReSharper

ReSharper makes a clear delineation between the concept of a formatter (a component that changes the way code looks but does not change the syntax) and the code style settings, a piece of functionality that can, in fact, change syntax without changing the semantics. This blog post covers the updates to the code style settings that appear as part of ReSharper 10.

For example, no keyword has caused more C#-related holy wars than the ubiquitous var. Well, ubiquitous for some, since many people still prefer to hold a belief that var is a form of obfuscation. The choice of using or not using var is, of course, personal, and so it makes sense for ReSharper to provide settings for controlling how things like var, this. qualifiers, and other constructs are used in code.

ReSharper code style settings

These Code Style Settings exist in many languages: ReSharper supports them in C#, VB.NET, JavaScript/TypeScript and, of course, C++. Each of the settings generally consists of three distinct parts:

  • The setting description is fairly self-descriptive, though some settings are grouped and, in some cases, you can collectively change a setting for the entire group.
  • The preference determines how code is actually used. In some cases this is a yes/no switch (e.g., whether or not you want to use a private modifier explicitly), in other cases it’s a list (e.g., for var usage), and then there are more complicated settings such as the order of modifiers.
  • The notify with option, which is only available on some code style settings, lets you control how a setting violation is presented: as a hint, suggestion, error or warning or… avoid notifying the user altogether.

That last option, the one used for notification, essentially controls if and how the existing code is treated by ReSharper. For example, adding a redundant this. not only gets ReSharper to ‘gray out’ the redundant prefix, but offers extensive options for fixing the problem:

Quick-fix to remove this qualifier

Since this. is a piece of redundant code, ReSharper offers an extra option here to remove all redundancies. Naturally, both of the presented actions support the Fix in Scope mechanic, so they can be applied to the entire file, folder, project or solution.

In аdditiоn tо this mесhаniс, in RеShаrреr 10 yоu саn аlsо соnfigurе the insресtiоn right in that sаmе рор-uр mеnu. Yоu саn control insресtiоn severity:

Configuring ReSharper inspection severity

Note that, in the above, you can disable the inspection completely by choosing the Do not show option. It’s also worth noting that the above configuration feature applies to any kind of inspection, not just those related to code style!

Yоu саn соnfigurе the соdе style itsеlf, tоо!

Configuring code style inline

Оh, аnd if there’s а раrtiсulаrly wоrrying issue, yоu саn sеаrсh fоr it, аnd this аlsо fоllоws the Fiх in Sсоре mесhаniс insоfаr аs yоu’rе аblе tо sеаrсh fоr this type оf issue аt diffеrеnt sсореs:

Searching for similar issues

And while we’re on the subject of the Alt+Enter menu, check out a recently added option called Format Selection. Nothing to do with Code Style but still very cool (and yes, it re-formats the selected code according to your preferences):

Format code selection

One of the key aspects of code style settings is that, just like other ReSharper settings, you can share Code Style settings with your team, thereby enforcing a consistent style. You can find more info about settings here. Though, if you have been using earlier versions of ReSharper, ReSharper’s Options dialog has a separate item called Code Style Sharing for importing code style settings saved in ReSharper versions earlier than 6.1.

Now, for a look at some updates in ReSharper 10 specifically.

First of all, there are now settings for Attribute placement, so you can choose whether to keep attributes on a single line or several lines.

Code style attribute placement

ReSharper also got very smart about parentheses: even though it can detect redundant parentheses and eliminate them, ReSharper knows full well that sometimes you want to keep redundant parentheses so as to clarify the order of precedence, e.g., in logical operations. For this, we have a new setting:

Code style order of precedence

Furthermore, not only is ReSharper smarter in removing the parentheses, it can help you insert those that clarify the operations. This is what the nearby Add parentheses to avoid non-obvious precedence feature is for. First of all, you can specify what operators you want to clarify:

Code style add parentheses to avoid non-obvious precedence

And, with this setting, you can move to an expression, press Alt+Enter and ReSharper will insert the relevant operators for you:

Code style clarify precedence with parentheses

Finally, ReSharper lets you take control of access modifiers: you can now specify whether you want explicit or implicit private/internal modifiers, and you can also control the order of modifiers that you’d prefer to appear next to an identifier:

Code style modifiers order

Enjoy!

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

Timeline Profiling inside Visual Studio

With each new release, dotTrace deepens its integration with ReSharper and Visual Studio. In doing this, we aim to lower the entry barrier and make profiling easier to use on a daily basis, by moving profiling closer to code. dotTrace 10 has come the farthest in this regard, as this release integrates the entire Timeline Viewer into Visual Studio.

The viewer is represented with the Performance Profiler tool window, exposing functionality that is almost identical to that of its standalone counterpart.

Performance Profiler tool window

What are the pros of using the integrated viewer?

  • First of all, the timeline profiling workflow becomes virtually seamless as you run a session and analyze results right in Visual Studio. You no longer need to switch between the source code and the profiler.
  • The next game changer is the ability to navigate from the call tree to the source code…
    Navigate to code from Performance Profiler
    …and vice versa:
    Navigate from code to Call Tree

In the latter case you not only navigate to Call Tree, but also apply a filter by all method occurrences and their subtrees.

Some differences between the Performance Profiler window and the standalone viewer:

  • With a more compact UI, filters are grouped in a slightly different way.
  • A tiny difference in Call Tree shortcuts is that in the integrated viewer, Enter navigates you to the method declaration.
  • Threads Diagram is not available in the integrated viewer. For thread selection, you can use either the Threads filter or the Threads tool window (for multiple thread selection).
    Threads filter and window

Try the integrated viewer on your own by installing the latest ReSharper Ultimate build and let us know how you like it!

Posted in dotTrace Tips&Tricks, How-To's, ReSharper Tips&Tricks | Tagged , , , , | Leave a comment

Hiring a Developer Advocate for .NET

[NOTE: This call is now closed]

We are looking for someone who

  • Believes in tooling and what we do at JetBrains
  • Is passionate about programming languages
  • Loves teaching, learning, producing content and speaking in public
  • Doesn’t need or like micromanagement
  • Doesn’t mind working from home. Or from an office
  • And last but definitely not least, loves to write code

What we’d need is someone with the following qualities:

  • A Developer, with experience in .NET/C#
  • A Teacher, with experience giving presentations and/or workshops
  • An Author, with experience producing content
  • A Traveler, located in the US*

If you’re up to it, ping me. Let’s have a chat.

*Ideally in the US because we need someone to be more present at events on that side of the pond.

Please don’t leave contact details in comments. 

Posted in News and Events, Other | Leave a comment

Project Rider – A C# IDE

UPDATE: NDC London organizers have kindly uploaded the recording of Project Rider presentation. Enjoy!


UPDATE 2: Make sure to follow Project Rider on twitter to receive further updates promptly.


UPDATE 3: We have opened a form for you to subscribe to take part in Project Rider Early Access Program. To everyone who subscribes, we will be sending links to Project Rider builds as soon as they are ready.


Today, at NDC London, we announced a new project that we’ve been working on for a little while – a cross-platform C# IDE, based on the IntelliJ Platform and using ReSharper technology.

Under the codename Project Rider, the IDE includes a lot of functionality that you are already familiar with from ReSharper and IntelliJ-based IDE’s, such as Quick Fixes, Inspections, and Smart Navigation. And while ReSharper is hosted inside Visual Studio, Project Rider is a full, standalone IDE.

While it’s still quite early, the following features are already available:

Navigation – smart navigation is a major feature of JetBrains IDEs, and Project Rider is no different, offering the standard Go To Type, Go To File, and integrating with IntelliJ Platform’s “Search Everywhere” feature to go to symbols, types, files and even search in settings and actions.

Rider Search Everywhere popup

The Navigate To popup menu is also available, giving access to navigate base/derived symbols in a class hierarchy, or to find usages, with the results displayed in the standard IDE tool window.

Rider Navigate To context menu
Rider Find Usages results

Editing – a wide range of smart editing features are implemented, from typing assist, such as inserting braces and automatic formatting, to Live Templates (including ReSharper 10’s postfix templates), quick info tooltips and gutter icons for inheritance navigation, context actions and so on.

Rider editing

Inspections – most of the inspections supported by ReSharper are displayed as errors, warnings, suggestions and hints in the editor. This includes red code for unresolved symbols, and underline highlights for code issues, and so on.

Rider inspections

Alt+Enter – no JetBrains IDE would be complete without Alt+Enter support, and most of the menu items from ReSharper’s quick fixes and context actions are available. Project Rider also supports applying bulk actions to a whole file, and changing the severity of an inspection directly from the menu.

Rider's Alt+Enter menu

Refactorings – a limited set of refactorings are available. Most refactorings require a user interface of some kind, and these haven’t been implemented yet. Project Rider can rename symbols and introduce/inline variable, as well as rewrite code in response to Alt+Enter on an inspection highlight.

Rider introduce variable

Decompiler – if you try to navigate to a type that you don’t have the source to, we’ll decompile it for you, and display what the C# source would like look.

Of course, as a standalone IDE, it also brings many other features to the table:

  • Multiple runtime support. Project Rider supports the .NET Framework and Mono, with CoreCLR support in the works. It can load MSBuild and Mono XBuild solutions, as well as DNX projects. It also includes templates for creating new projects. And when you create an empty project, it’s really empty!

Rider new project templates

  • Build, run and debug. One of the most important features of an IDE is debugging, and Project Rider is no exception. It can build and run .NET Framework, Mono and DNX projects, and can debug .NET and Mono apps – DNX debugging and CoreCLR support are coming. Any build errors are displayed in a Build tool window, and the Debug tool window is used for call stacks, variables and watch windows.
  • Cross platform. As well as running and debugging multiple runtimes, Project Rider itself runs on multiple platforms. It runs on Windows and Mac OS X (Linux too, but it’s mostly untested right now).

How does it work?

Project Rider is a standalone IDE built on the IntelliJ Platform, much like WebStorm, DataGrip and our other IDEs.

The difference however, is that instead of reimplementing ReSharper’s features on the IntellIJ Platform, which runs on the JVM, we’re using ReSharper in a headless mode, out of process, and communicating with it via a very fast custom binary protocol. As such, the backend continues to be ReSharper written in C# running on .NET or Mono, and the frontend is written in Kotlin, talking to the IntelliJ Platform’s APIs.

We’ll take a more in-depth look at the implementation details in a future blog post.

Why have we created a C# IDE?

Well you kept asking us, so we finally got around to doing it!

Jokes aside though, our main reason is to provide choice. We believe that we can provide a great user experience for developers that might be interested in using alternative environments.

So why now? Because we believe it is the right time due to several factors:

  • We’ve been working for several years in allowing ReSharper to work in different environments, independently of Visual Studio. An example of this is dotPeek.
  • It’s quite clear that there’s an ever increasing tendency of developers using non-Windows platforms, and we’d like to give them the same experience they’ve come to know and love with ReSharper.
  • Finally, Microsoft moving its platform and C# language towards Open Source, along with initiatives such as CoreCLR, have been an added incentive.

What does this mean for ReSharper?

ReSharper is still the number one extension for Visual Studio, and one of our flagship products. The fact that Project Rider is using ReSharper reinforces our commitment to ReSharper, as any updates to ReSharper mutually benefit not only ReSharper but Project Rider also. In addition, we’re hoping some of the work we’ve put into Project Rider can feed back into ReSharper.

In essence, Project Rider will only increase the efforts we put into ReSharper.

What will the licensing model be?

While it’s too early right now to comment on the specific details, the licensing model will be inline with our other products from the JetBrains Toolbox. We will take into account the many usage scenarios that might occur, when establishing pricing, such as someone wanting to use both tools, etc.

We hope to have the pricing information soon.

Roadmap

We’re starting out on the road to 1.0. We’re confident of the architecture, and believe we’ve built a good foundation to implement the features we want to see in a 1.0 release. We’ve got a lot of functionality already implemented, but we’ve still got a lot that we need to build.

We’re aiming to open a private EAP in the coming weeks, towards the end of February. We’ll announce the signup form here on the blog, as well as on Twitter.

Soon after the private EAP we’ll move to a public EAP. When this will happen very much depends on the feedback we get from the early testers. Our aim is to release sometime in Autumn 2016.

We are very excited with Project Rider and hope you share the excitement. If you have any questions, please, ask away. And don’t forget to follow @JetBrainsRider for updates!

P.S. Of course, if you’re at NDC London this week, pop over to the booth and we’ll be happy to show you Project Rider in action!

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

Shadow-copying in dotCover: if your NUnit tests fail during continuous testing

When dotCover 10 came out, early users of continuous testing faced a problem: tests that used external files could fail in a continuous testing session while being successful in a ‘normal’ unit testing session. The issue was related to how dotCover worked with unit test assemblies.

To run a continuous testing session in the background, dotCover doesn’t use the original unit test assembly: instead, it creates a copy using the shadow-copying mechanism. Along with assemblies and symbol files, dotCover 10 and 10.0.1 also copied the entire content of the directory where the original assembly was located, be it a default location (e.g., …/bin/Release/) or a custom location specified by the option ReSharper | Options | Unit Testing | Run tests from.

If a unit test works with a file (using its relative path) that is located outside this directory, the test will fail as it looks for the file relative to the new temporary location. For example, the following test (used to process a file in some way) fails in a continuous testing session but passes in a ‘normal’ unit testing session.

Failed test in a continuous testing session

Successful test in a normal session

To address the issue, dotCover 10.0.2 introduced a new option, ReSharper | Options… | dotCover | Continuous Testing | Shadow-Copy.

Shadow-copy option

If this option is set to Assemblies and symbol files, dotCover will copy to a temporary location only assemblies and PDB files without touching other data. In this case, the working directory for tests will be the initial location of test assemblies (e.g., …/bin/Release/). Therefore, the sample test from above will pass successfully in both continuous testing sessions and traditional unit testing sessions.

Successful test in a continuous testing session

However, if All files from the tests start folder is selected, dotCover works as before. It copies the entire content of the tests’ start directory. In this case, the path ..\\..\\Test Files\\1.txt will refer to the new temporary location, causing the test to fail.

IMPORTANT! The Shadow-Copy option works as described ONLY with NUnit tests. All other unit testing frameworks use shadow-copying at their discretion depending on plugin implementation. For example, MSTest may decide to disable shadow-copying in a particular case (regardless of the Shadow-Copy option).

To simplify using continuous testing, you may want to change the way you reference files in tests. Here is a short table showing how you can build paths to the tests working directory. Source here refers to the initial directory where the unit test assembly is located; Temp means the temporary directory where the assembly copy is located.

Assemblies and symbol files All files from the tests start folder
Assembly.GetExecutingAssembly().Location Temp Temp
Assembly.GetExecutingAssembly().CodeBase Source Temp
Environment.CurrentDirectory Source Temp
AppDomain.CurrentDomain.BaseDirectory Source Temp
TestContext.CurrentContext.TestDirectory (NUnit 2.6) Source Temp
TestContext.CurrentContext.WorkDirectory (NUnit 2.6) Source Temp
Posted in dotCover Tips&Tricks | Tagged , , , , , , | 2 Comments