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 , , | 262 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

End of Year Round up of ReSharper 10 Extensions

With the end of the year just around the corner, ReSharper 10 released less than two months ago, and having just released our second maintenance release, it’s a perfect time to take a look at some of the extensions we’ve got available for ReSharper 10.

ReSharper provides a very rich extensibility platform. It is a very modular application, composing functionality and features via a component container. Extensions can extend existing functionality, such as adding items to the Alt+Enter menu, or new inspections and Quick Fixes, or add new functionality, such as support for new languages, or synchronising settings via DropBox.

We currently have about 60 extensions available in the Extension Manager for ReSharper 10. If you haven’t yet had a look to see what’s available, grab yourself a coffee and we’ll take a wander through some of what’s out there. If you see anything you like, head over to the Extension Manager under the ReSharper menu, and search for the extension you want.

ZenSharp

The ZenSharp extension is like ReSharper’s Live Templates on steroids. While Live Templates will expand a static shortcut (like tm) into a code snippet (such as a test method), ZenSharp uses “dynamic” shortcuts to customise the generated snippet.

For example, pc will expand to public class $Name { }, where $Name is a standard Live Template “hotspot” to edit the class name. But pcPerson will expand to public class Person { }.

Similarly, pmSayHello  will expand to public void SayHello() { }. And pmsSayHello will expand to public string SayHello() { }.

The shortcuts are defined to be intuitive mnemonics that can be combined and built up to make it easy and fast to create classes, methods, properties, fields and so on. Standard types can be specified as part of the mnemonic shortcut, and once you’ve mastered it, there’s no faster way to create types and type members.

ZenSharp creating code really quickly

Enhanced Tooltips

The Enhanced Tooltip extension gives ReSharper’s tooltips a facelift. While this doesn’t exactly sound like it’s a big deal, it has a surprising impact – tooltips and parameter info popups in C# are rendered with syntax highlighting, which makes quickly reading parameter lists and method names a whole lot easier.

Furthermore, the tooltips that appear for ReSharper’s inspection warnings and suggestions are also syntax highlighted, with any member names in the message being rendered correctly, and an icon showing what kind of message is being displayed. ReSharper never looked so good!

Enhanced tooltips

ReSpeller

Office has it, so why shouldn’t ReSharper? Spelling, that is, and the ReSpeller extension provides just that. It’s available in Free and Pro versions and will look for typos in different languages, such as C#, VB and XML, and even differentiates between identifiers, string literals and comments. For example, you can configure typos in identifiers to be shown as a “hint”, and change typos in comments (such as XML documentation) to be “warning”. And it understands “CamelCasing”, treating “SayHelo” as two words, and finding the typo in “hello”.

It also supports the Alt+Enter menu, offering a Quick Fix to replace the typo, or options to add the word to the user dictionary.

The Pro edition adds extra features, like enabling support for extra languages (such as JavaScript, HTML and Razor), multiple language support and even spell checking directly in the Rename refactoring dialog box!

ReSpeller showing typos

StyleCop

While the StyleCop project itself has stalled, there are still many people using it to maintain a very consistent style when writing code within a team. The StyleCop extension provides as-you-type inspections to highlight when your code doesn’t match the expected style. It also configures ReSharper so that the code ReSharper produces or formats is in the correct style.

We find ourselves in the unfortunate position of having two different StyleCop extensions available in the Extension Manager (it’s a long story, sadly, and we’re working to resolve it). We strongly recommend you use the StyleCop by JetBrains version (search for “StyleCop by JetBrains” in the Extension Manager), as it fixes many issues, including exceptions and memory leaks, and implements improved performance throttling. It also doesn’t need the StyleCop Visual Studio plugin installed.

One thing to note is that StyleCop itself does not support C# 6. The StyleCop engine that the extension uses has a custom C# parser, rather than using ReSharper’s already parsed abstract syntax trees (one cause for performance issues), and due to the project stalling, the parser hasn’t been updated for C# 6. If you’re using Visual Studio 2015 and C# 6, we recommend you use the StyleCopAnalyzers project, which has full support for C# 6, including new rules. When the StyleCop by JetBrains extension sees that StyleCopAnalyzers is installed, it disables its own as-you-type analysis, but still provides code cleanup features and configures ReSharper to match the StyleCop settings.

StyleCop showing warnings

Extra inspections

Some extensions are designed to add new inspections, and we’ll take a look at two – Cyclomatic Complexity and Heap Allocations Viewer.

The Cyclomatic Complexity extension calculates the cyclomatic complexity of a block of code. This is a measurement of how complex your code is, and you should ideally be aiming for a very low figure – the higher the value, the more complex the code, and the harder it is to maintain and understand. The value is always shown in a tooltip, and if it’s over a certain configurable threshold, the method name (or similar) is highlighted as a warning. The extension works with C#, VB, JavaScript, TypeScript and C++.

ReSharper showing high cyclomatic complextity

The Heap Allocation Viewer extension highlights all allocations made by your code. This is an interesting extension, because it doesn’t indicate that anything is actually wrong, but it’s intended to make you aware that an allocation happens here. This is very useful when writing performance critical code, when you really need to keep track of all allocations. While it’s obvious that the new statement will allocate memory, this extension will also highlight less obvious allocations, such as boxing, string allocation, allocations when iterating with a foreach loop, and so on.

Heap allocations viewer showing boxing

Working with open source libraries

While some extensions are designed to provide new functionality across the product (such as improving the editing experience, or more inspections for your code), others are designed for a specific library or framework.

A good example of this is support for AngularJS, parsing your JavaScript code to pull out Angular directives, and add them to your HTML code completion. It will also provide improved code completion for the services and providers injected into controllers and directives.

AngularJS intellisense for injected parameters

Similarly, Unity support provides features for users of Unity 3D. It will mark methods and fields used by Unity as being in use when Solution Wide Analysis is enabled, generate message handlers via the Generate Code command and automatically mark a C# project as C# 5, so ReSharper won’t suggest incompatible C# 6 features when the project is opened in Visual Studio 2015.

Working with commercial libraries

A very nice use of ReSharper extensions is supporting commercial frameworks and products. The team at Trackerbird have done just that, and released an extension that will make it very easy for you to integrate their analysis SDK into your own project. Once installed, this extension adds an item to the ReSharper menu, offering options to set up the SDK in your project, add simple or detailed event tracking code to your project, help you implement checking for updates and so on. It also includes a context action on Application.Run that will add the code necessary to initialise and start activity tracking in your app.

Implement Trackerbird as a context action menu item

Please check out the Trackerbird blog for more details.

Annotations

ReSharper extensions are not just about custom code adding new items to the Alt+Enter menu, but can also include “external annotations”. These are files that contain annotations for pre-compiled assemblies that in turn provide hints to ReSharper’s inspections, resulting in better analysis for features such as null analysis, string formatting highlighting and telling ReSharper that type members are used externally from the code. Here are some annotations packages:

  • Community External Annotations – this is a nice open source project that maintains annotations for a number of third party libraries, as well as adding extra support for various BCL libraries. You can see the list of supported assemblies in the project readme. Contributions welcome!
  • NLog Annotations – adds null analysis and string formatting highlighting annotations for the NLog framework.
  • Caliburn.Light Annotations – adds annotations for the Caliburn.Light MVVM framework

Live Templates

Alongside external annotations, ReSharper extensions can also include settings files, which are automatically merged into ReSharper’s settings (technically, they override ReSharper’s defaults, and can get overwritten by your own settings). One of the more interesting uses for this is to package up a settings file that contains Live Templates.

There are several such packages available in the Extension Manager, such as:

  • SpecsFor templates for the SpecsFor BDD framework
  • Joar Øyen’s Live Template Macros – adding templates for BDD and a macro that converts a Live Template “hotspot” into a “snake_case_identifier”, such as given_a_new_customer .

Presentation Assistant

This extension is very useful when you find yourself giving a presentation. It will display the name of the last command run, and the keyboard shortcuts used to run it, allowing everyone to follow along with the steps you make as you make them. It shows both ReSharper and Visual Studio commands, and can be enabled from the ReSharper → Tools → Presentation Assistant.

Presentation Assistant showing keyboard shortcuts

It’s also useful for pair programming, to stop the “how did you do that?!” questions as you show off your mad keyboard skillz.

Working with settings files

Two useful extensions for working with settings files are ReSharper Solution Settings Autodiscovery and JetBox.

ReSharper already allows you to share settings files per-solution, by creating a .sln.DotSettings file that lives next to your solution file. But this needs setting up for each solution – what if your team has a number of solutions that you want to work with?

The ReSharper Solution Settings Autodiscovery extension will look for a settings file in each of the parent folders when opening a solution. So if your solution is in C:\projects\team\solution\mySolution.sln, this plugin will look for any file that ends in *.AutoLoad.DotSettings in any of the parent folders – C:\projects\team\solution, C:\projects\team, C:\projects and so on, up to the root of the drive. This is ideal when working on a source control check out that has multiple solutions, and allows you to easily share settings between all of them, and still have the file checked into source control.

The JetBox extension will sync your global settings via DropBox. Simply log in to DropBox via the options page, and the global settings file will be synced whenever there are any changes. And because ReSharper automatically refreshes the settings in any running instances whenever the file changes, you don’t even need to close and reopen Visual Studio for the changes to take effect.

And Finally…

It doesn’t have to be all work and no play. We’ve got a couple of fun extensions too. Check out ReMoji, to add support for JBEvain’s EmojiVS extension to ReSharper’s code completion (make sure you read the instructions for installing first!)

Code completion showing emoji

And of course, who can forget Clippy?

inplace_refactoring.gif

We hope you’ve found this look at some of the extensions available for ReSharper 10 useful. It’s by no means all of the extensions that are out there, so please, have a scroll through the Extension Manager, and see if there’s anything else there that interests you.

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

Enters ReSharper Ultimate 10.0.2

Download ReSharper Ultimate 10.0.2, which includes a slew of bug fixes and improvements to ReSharper, ReSharper C++, dotTrace, dotMemory, dotCover and dotPeek.

ReSharper Ultimate 10.0.2

Highlights of this update

  • Unit testing. In addition to support for NUnit 3.0 RTM, unit testing has seen noticeable improvements in terms of support for test cases and grouping, handling of debugging sessions, time spent for setup and teardown code runs. Many presentation glitches in Unit Test Sessions have been fixed as well.
  • Bogus red code. We have fixed incorrectly highlighted red code in solutions containing .modelproj and .wixproj project types, as well as in DNX projects, projects targeting .NET Framework 4.6 and portable libraries.
  • ReSharper Build. There’s an array of improvements in the way ReSharper Build works, notably with regard to monitoring changed dependencies, respecting settings that govern whether to display results upon completing a rebuild, and better support for specifics of Visual Studio 2015.
  • JavaScript and TypeScript. Improvements include a performance tuneup, as well as fixes to incorrect code inspections, usage search and navigation.
  • In other news, Stack Trace Explorer has received a set of fixes; you can now disable ReSharper code tooltip if you prefer how other Visual Studio extensions decorate the tooltip; introducing a variable from inside a lambda expression doesn’t produce broken code anymore; and you can export items from File Structure again!

ReSharper C++, dotCover, dotTrace, dotMemory and dotPeek have received their varying shares of bug fixing in the past month but it’s ReSharper that leads the breed in terms of sheer number of improvements. For your reference, this is how distribution by subsystem looks like for issues fixed in ReSharper 10.0.2:

ReSharper 10.0.2: fixed issues by subsystem

If you’re interested, here’s the entire list of fixes across ReSharper Ultimate products.

Important note to Visual Studio 2015 users

If you have migrated to Visual Studio 2015, please make sure to install VS2015 Update 1. This is especially important if you are experiencing Visual Studio freezes upon starting debugging, pulling from your VCS repository, starting a refactoring, editing XAML in visual mode or in other scenarios described in comments to RSRP-450181. Visual Studio 2015 Update 1 is known to fix a part of MSBuild calls that these freezes are usually traced back to.

Time to download

Upon reading the above, we hope you’re now well prepared to download and install ReSharper Ultimate 10.0.2.

This release wraps up the year for the .NET team here at JetBrains. We’d like to welcome 2016, and we’re hoping to open EAP for a new ReSharper Ultimate release sometime in January.

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

Navigating to Source Code from dotMemory

We always look for ways to increase the value of ReSharper Ultimate and synergize our .NET tools. For example, in ReSharper Ultimate 9.2, we made it possible to profile ReSharper’s run configurations, so if you have both dotTrace and ReSharper you can even profile individual static methods in your project.

Now the time has come for dotMemory to get its portion of ReSharper’s functionality. dotMemory always lacked the ability to examine the source code of the profiled application. Just imagine how easier life would get if you could seamlessly continue the investigation of a suspicious object (one that may cause a leak) by examining its source code. Well, starting with dotMemory 10 and ReSharper Ultimate 10, you can!

To navigate to the source code from dotMemory

  1. In Visual Studio, open the solution that you have a memory snapshot for.
  2. In dotMemory, in any view that displays object types, right-click the type you’re interested in.
    Find declaration context menu
  3. In the context menu, select Find declaration (Visual Studio)*. This will open the Find Type Declaration window that lists all found type declarations in running Visual Studio instances.
    * As an alternative to steps 2 and 3, select a type and press Ctrl+L.
    Find type declaration window
  4. Click on the found declaration to navigate to it in Visual Studio.
    Type declaration in VS

After you navigate to any type declaration at least once, the context menu will offer an additional item, Go to declaration (<solution_name>) (also available via the Ctrl+L shortcut). Selecting it instantly navigates you to the type declaration in a specific solution, bypassing the Find Type Declaration window.

Go to declaration context menu

To see for yourself how the feature works, download the latest dotMemory or ReSharper Ultimate. If you have any comments or questions, please feel free to ask in the comments to this post. Your feedback is greatly appreciated!

Posted in dotMemory Tips&Tricks, How-To's | Tagged , , | 1 Comment

Continuous Testing webinar: recording

The recording of our recent webinar, Continuous Testing in Visual Studio using dotCover or ReSharper Ultimate, is now available:

In this webinar, we demonstrate Continuous Testing, a new feature of dotCover 10 and ReSharper Ultimate that will build and run your tests as they change. By monitoring what code is called from each test, Continuous Testing can optimise the test run by only running the tests that will exercise the changed code. ReSharper Build can also be used to further optimise the feedback cycle by speeding up the build step.

The following topics are covered:

  • A recap, with some hints and tips of ReSharper testing and dotCover code coverage
  • Enabling Continuous Testing
  • The Continuous Testing UI
  • Detecting “dirty” tests
  • Including/excluding tests from scope
  • Using ReSharper Build to speed up build time

You might also want to check out two related blog posts: Introducing Continuous Testing and Introducing ReSharper Build.

Posted in dotCover Tips&Tricks, ReSharper Tips&Tricks | Tagged , , , , , , | 3 Comments

ReSharper Ultimate 10.0.2 EAP 2: unit testing, red code fixes

ReSharper 10.0.2 EAP continues with a new build that is expected to fix a number of considerable problems in terms of:

  • Bogus red code: we have fixed incorrectly highlighted red code in solutions containing .modelproj and .wixproj project types. Since modelling projects (.modelproj) are only available in Visual Studio Enterprise and Ultimate editions, users of these editions might want to check out this fix.
  • Unit testing: NUnit tests with Ninject should now be running correctly again; NUnit’s test cases are now treated with fewer glitches; a set of problems related to grouping by category and namespace are now gone; unit test runner avoids running extra setup and teardown code for test fixtures; running the default NUnit 3.0 MSI installer no longer leads to inconclusive test runs; support for xUnit theory row test elements is restored following a regression in 10.0.1; line wrap in Unit Test SessionsOutput pane can now be controlled.
  • Inserting project references: projects should now be properly referenced again when you insert a using directive with a ReSharper action.

There are also other fixes here and there, including those related to TypeScript and JavaScript support, as well as renaming namespaces in XAML. Here’s the full list of fixes in ReSharper 10.0.2 EAP 2.

Compatible ReSharper Ultimate products are also available. Specifically, dotCover can now be properly integrated into Visual Studio again, even when installed without ReSharper, which fixes a regression introduced in EAP 1.

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

ReSharper Ultimate 10.0.2 EAP

As we continue working on critical issues discovered in ReSharper 10, today we open the Early Access Program for ReSharper Ultimate 10.0.2.

The initial EAP build is mostly about Unit Testing, it comes with fixes to such issues as inabilty to run a single test or a group of selected tests with NUnit 3.0 (RSRP-450313), broken key bindings (RSRP-429324) or hanging Visual Studio (RSRP-449802).

Here is the full list of fixes for ReSharper for your reference. ReSharper C++ 10.0.2 EAP introduces a set of performance improvements and bug fixes as well.

Please download and try the ReSharper Ultimate 10.0.2 EAP build and let us know if it improves your experience with ReSharper compared to previous versions (10.0 and 10.0.1). ReSharper 10.0.2 release is currently planned for mid-December, so please expect more EAP builds in upcoming weeks.

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

Continuous Testing in dotCover and ReSharper Ultimate

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

Continuous testing

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

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

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

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

1. Open Continuous Testing Session window

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

Continuous testing is off by default

2. Select continuous testing mode

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

Select continuous testing mode

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

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

3. Just work

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

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

Continuous testing status

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

Working with continuous testing

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

Failed test icon

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

Show covering tests

Next steps

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

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

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

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

ReSharper Build webinar: recording and Q&A

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

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

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

Questions and Answers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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