Joe White’s Blog

Welcome to day 10 of my 31 Days of ReSharper.

Today’s topic is Ctrl+N: Go to Type.

You press Ctrl+N, and a little window pops up. You type in part or all of a type name, and it shows you a list of matches. Then you select one and press Enter, and it opens that file.

The only time you still need Solution Explorer is when you’re adding new files. Other than that, Ctrl+N is about all you need.

And it has shortcut features:

• Search by title caps. If you type capital letters, it will try to match as if you were typing an acronym. So if you type MDT, it will match MyDataTable and MenuDropTag. (You can mix and match this with ordinary searching, so you could search for MDatT and find MyDataTable.)

• Wildcards. You can type * to match zero or more characters, or + to match one or more characters. (This is a fileglob-style wildcard; it means “zero or more of any character”.)

Ctrl+N is in fairly direct competition with VSFileFinder; they both do pretty much the same “let me see a list of files matching a particular pattern so I can open one of them” thing. So I figured it’d be interesting to compare the two. Here’s how they stack up:

• Stuff where ReSharper is definitely better:

• VSFileFinder doesn’t support the title-caps thing that ReSharper has.

• Ctrl+N already has a keybinding, whereas I’ve never been able to bind a keystroke to VSFileFinder that survived exiting and restarting Visual Studio.

• Ctrl+N goes away as soon as you’re done with it, whereas VSFileFinder is a dockable window that keeps taking up space even after you’re done searching.

• Stuff where VSFileFinder is a little better:

• Neither tool requires you to know the entire name of the thing you’re searching for; they both let you specify parts of the name. However, VSFileFinder lets you specify those parts in any order; data table would match both DataTable and TableOfData. ReSharper is more limited; you have to specify the parts in the same order they appear in the type name (and you have to remember to type * between each one, instead of being able to just type a space in VSFileFinder).

• Searching by substring is much easier with VSFileFinder. If you want to find all types that contain “Foo” anywhere in their name, you have to type *Foo in ReSharper, whereas with VSFileFinder you only have to type Foo.

• Stuff where VSFileFinder is definitely better:

• VSFileFinder makes it easy to open multiple files at once (precisely because the window is always visible and taking up space). This is a real win for tests — you can type Foo, see both “Foo” and “FooTests” in the list, and click on both of them to open both files. ReSharper doesn’t have this option.

That last item, in particular, illustrates that ReSharper and VSFileFinder are aimed at subtly different goals, and both tools have their place. (We have both of them installed on all of our development PCs.) But of the two, I usually end up using ReSharper’s Ctrl+N. That bit about having a keystroke bound is pretty persuasive.

If for some reason you don’t keep one class per file, you might also be interested in Ctrl+Shift+N, which searches on filenames (instead of type names like Ctrl+N does).

Welcome to day 9 of my 31 Days of ReSharper.

Yesterday I talked about one Visual Studio feature (Find All References) that ReSharper replaced, enhanced, and changed the keystroke for. Today I’ll talk about another: Parameter Info, formerly Ctrl+Shift+Space.

ReSharper’s parameter info, accessible via Ctrl+P, shows all the overloads at once, instead of just one like Visual Studio’s:

Visual Studio’s parameter info

ReSharper’s parameter info (click to enlarge)

If the method you’re calling doesn’t have any overloads, ReSharper’s parameter info is pretty similar to Visual Studio’s. But if you ever call overloaded methods (i.e., if you ever use anything in a Microsoft-provided assembly), the new parameter info has several decided advantages:

• See where you’re going. Whenever I’m writing custom painting code in .NET, I have to face the dreaded Death by Overload. Seriously, what is up with System.Drawing? Some of the methods have 30 different overloads. When you know you want an overload that takes ImageAttributes (and of course they’re all way at the bottom of the list), it’s nice to be able to see lots of overloads at once.

• You can use the cursor keys! When Visual Studio’s Parameter Info tooltip is visible, you can’t use the up and down cursor keys — VS hijacks them to mean “show the parameter info for the next/previous overload”. I’ve had to develop the habit of hitting “End” followed by “Right arrow” when I want to move to the next line (or “Esc” followed by “Down arrow”, but those keys are a lot farther apart…) But with ReSharper, you use Ctrl+P and Ctrl+Shift+P to cycle through the overloads, not up and down. So the cursor keys are available for actually moving through your code. Sweet!

• Skip the ones that don’t apply. When you use Ctrl+P and Ctrl+Shift+P to cycle through the overloads, it will only step to the overloads that match the parameters you’ve already entered. For example, in the above code, I’m calling Graphics.DrawImage, and passing an Image and an int. If I press Ctrl+P again, it will skip the next overload in the list, because it takes a Rectangle as its second parameter — obviously not one I want, because I’m not passing a Rectangle. Instead, it will go two down, to the next overload that takes floats.

According to their Web site, ReSharper’s parameter info is supposed to show inapplicable overloads in gray. Unfortunately, this feature is broken in ReSharper 2.5.1 (I told support about it, and they said it’s supposed to work; they’re looking into it.)

Welcome to day 8 of my 31 Days of ReSharper.

As I mentioned in the survival guide, ReSharper replaces Visual Studio’s Find References (Shift+F12) with its own Find Usages (randomly changed to Alt+F7). Here’s more info on how their version differs from the one in Visual Studio.

Filtering for “get” or “set” usages

Ever had a property that’s read all over the place, but only set a few places, and you wanted to Find References to just the property setter? Here ya go.

This also applies to fields: you can find only places where a field is read, or only places where it’s written. (Man, if Reflector only had this feature!)

As you can see from the screenshot, the Filter menu in the Find Results window has options for “Show Read Usages”, “Show Write Usages”, “Show Invocation Usages”, “Show Other Usages” (I’m not sure what that means), and “Show Usages in Documentation” (I assume this means XML doc comments). I thought “Show Other Usages” would mean making a delegate that references a method, but apparently they use “Show Read Usages” for that.

They’ve said that in a future version, you’ll be able to right-click on the “get” or “set” keyword inside a property declaration, and select “Find Usages”, and get just the read or write usages, as appropriate. I’m looking forward to that one.

Stepping through the results

After you do a Find Usages, you can use Ctrl+Alt+Up and Ctrl+Alt+Down to step through the results. It’ll put the cursor on the next result, opening another file if necessary. It doesn’t wrap when you get to the end, which is nice in a way, because it tells you you’re done.

The Find Results tree

On the downside, I don’t really like the way they present the search results in the Find Results window.

In Visual Studio, everything was just shown in a list:

Every entry shows the filename and line number (and column number, as if you cared), so you at least know which class each reference is in. In ReSharper, on the other hand, everything’s in a tree:

The tree starts out collapsed every time, so you’re always at least one click (Expand All) away from even seeing your results. And if you change the “Group by” setting to “None”, in an attempt to get rid of those layers of tree and see your results right away, then you don’t get anything telling you which file a result came from: each line will show just the text of the matching line of code, but no filename or line number information.

(I sent in an enhancement request, asking for the ability to show the results expanded by default. They said that there were a lot of other people asking for the exact same thing, so we may see that happen at some point.)

On the other hand, once you do get them expanded, they can tell you not just which class the result was in, but also which method, something VS’s list doesn’t do.

Welcome to day 7 of my 31 Days of ReSharper.

ReSharper has a great deal of support for code formatting. It basically falls into three categories: as-you-type, on-demand per file, and on-demand for multiple files.

Formatting as you type

This doesn’t sound new, does it? Visual Studio has had this for a while now. But of course ReSharper’s formatting options are versionable and sharable, so you won’t have some computers putting a space after typecasts and others removing it. This alone is a win.

Another nifty ReSharper formatting feature is in how it handles Enter inside empty curly braces. It’s a little better than the way Visual Studio handles the same thing, and ties nicely in with the automatic closing delimiters:

Starting out with an empty statement.
Type an open curly brace…
and press ENTER.

Formatting an entire file: Ctrl+Alt+F

ReSharper also has a command to reformat the entire source file you’re working on. If you press Ctrl+Alt+F, you’ll get the “Reformat Code” dialog box:

Notice that it can do more than just tweak your whitespace. You can also tell it to fix some of those grays in your code. Optimize “using” directives” and Remove redundant ‘this.’ qualifier are pretty self-explanatory. Shorten references will change System.Drawing.Graphics to simply Graphics (adding the necessary using if needed).

We always check all of these boxes; we want our code as clean as it can get. It remembers your settings for next time.

Update: Maruis points out that Ctrl+Alt+Shift+F will do a silent reformat, without popping up the dialog, and just using whichever options you already had selected. Awesome! Thanks, Maruis!

Here are some other things ReSharper does when it reformats your code:

• Adds explicit visibility specifiers. If you have classes with no visibility specifier, it will add the internal for you. Fields with no visibility get the private added. (As with everything in ReSharper, this is configurable. So if for some reason you wanted your code to be less readable, you could turn this option off.)

• Puts simple getters and delegates on a single line. If the getter/setter/delegate body is a single statement (e.g., an assignment or a return), ReSharper will put it on a single line, along with the braces. So ReSharper would take this poorly-formatted code:

  public Color BorderColor {
      get
      {
          return _borderColor;
      }
      set { _borderColor = value; Invalidate(); }
  }

  and reformat it to look like this:

  public Color BorderColor
  {
      get { return _borderColor; }
      set
      {
          _borderColor = value;
          Invalidate();
      }
  }

  Since Visual Studio 2005 doesn’t bother showing the extra layer of “collapse” plus signs for single-line getters and setters, this is a really nice feature.

Reformatting a project or solution

Finally, ReSharper has an option to reformat lots of files at once. Simply right-click on a folder, project, or solution, and select “Reformat Code”.

It may be obvious, but is worth noting anyway, that if you’ve made any other changes to your code, you should commit them to your source-control repository before you do this. Reformatting an entire solution is worthy of its own commit. It will change things, sometimes in ways you don’t want, and until you either change its settings, or adapt to its quirks, you’ll probably want the chance to selectively revert some of its changes.

Things it doesn’t get quite right #1: delegate indentation

By default, ReSharper indents your inline delegates a ridiculous amount. This is one of those where I think they got the default wrong: I want my code to follow normal indentation. I don’t want half of it ragged-center-aligned like this:

Block incrementer = delegate {
                        ++i;
                        ++j;
                    };
Block resetter = delegate {
                     i = 0;
                     j = 0;
                 };

I did finally find the way to fix this. The options for formatting anonymous methods are spread across two separate pages in ReSharper options: Braces Layout and Other. The “don’t indent a ridiculous amount” is on the Other page, and it’s called “Indent anonymous method body”. Turn it off, and set the brace option to “At end of line”, and you get something much nicer:

Block incrementer = delegate {
    ++i;
    ++j;
};
Block resetter = delegate {
    i = 0;
    j = 0;
};

Things it doesn’t get quite right #2: Xceed licensers

ReSharper tries to shorten qualifiers as much as it can. In suitably odd circumstances, it can decrease readability. Here’s one such case, and how we worked around it (which I think worked out quite well).

We use Xceed components in our software. One of our big frustrations with Xceed is the way they do licensing: they give you a license key, which is one of those ridiculously long strings of letters and numbers, and at runtime you have to write startup code that puts the key into a static property, like this:

Xceed.Grid.Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Xceed.Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

Yes, you have to set a license key for each Xceed assembly you use. Otherwise, some of them will complain at runtime. (Some of them, oddly enough, won’t, but we set their license keys anyway, just to be sure.)

The oddness is with a class named LicenseKey in multiple different assemblies. ReSharper tries to shorten that like this:

using Xceed;
using Xceed.Grid;
...
Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

Yuck. Here’s how we worked around it; ReSharper leaves this version alone:

using GridLicenser = Xceed.Grid.Licenser;
using EditorLicenser = Xceed.Editors.Licenser;
...
GridLicenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
EditorLicenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

It’s a workaround for a tool limitation, but I think it actually reads better this way.

Welcome to day 6 of my 31 Days of ReSharper.

Sometimes we’ll end up with different IDE options on different computers. Since we all use all the machines in the bullpen, this tends to iron itself out over time, but it can be aggravating. It’s especially bad with code auto-formatting options, as files get reformatted automatically when we make seemingly unrelated changes like tweaking something on a design surface.

ReSharper to the rescue. Certain options are stored in a file in your solution directory: the .resharper file. Then you commit the .resharper file to your source-code repository along with everything else, and everyone on the team ends up using the same options.

There are two interesting things that get stored in the .resharper file: code-formatting options and templates.

Shared code-formatting options

As shown in the screenshot above (of ReSharper > Options > Code Style), ReSharper offers three different options for sharing code-formatting options:

• Globally for the current user only. This is the default, and it’s what you want if you only have one developer on one machine.

• Team-shared for the current solution. If you have multiple developers and only one Visual Studio solution, this is the option for you: everyone will use the same code-formatting options.

• From external file for the current solution. This is a little more work to set up, but is what you want if you have multiple solutions in the same source tree (like we do).

To use the last option, you need to use the Export button to save your settings to an .xml file somewhere; and then specify the path to that file. If you’re sharing the settings among several solutions that are all part of the same source tree, then you probably want to specify a relative path.

Shared templates

It used to be that, whenever we added a new class to our solution, we had to spend a few seconds cleaning it up: fixing the class visibility, cleaning up usings we don’t need. When we wanted a new interface, we had to do “new class” and then change the “class” keyword to “interface”. Little things, but shouldn’t the computer be able to automate that stuff for us?

ReSharper lets you define several types of code templates: Live Templates (the ones with those different fields you can tab to and fill in), Surround With, and File Templates. All of these are configurable, and they’re all stored in the .resharper file, so again, they’re automatically shared among everyone on your team.

ReSharper ships with some sample templates you can look at, to see how it’s done. But they’re annoying, because they add a comment block at the top of each file with spaces for “Author” and “Date” — and why would you want to duplicate this information, when you could just look at your source-code repository and see who added the file? (My guess is that they make it annoying on purpose, so you’re sure to try your hand at making your own templates. We did.)

Making your own templates is easy, if a bit quirky. I’ll note that it’s important to click the “Available everywhere” hyperlink, and tell it that no, it’s only available for C# (if you don’t do this, it forgets to add a filename extension, and won’t format the file properly). Also, if you want special placeholders like $NAMESPACE$, be aware that it doesn’t recognize them by name; you have to click “Choose macro” in the “Template variables” grid, and select a macro from the list.

Welcome to day 5 of my 31 Days of ReSharper, where I introduce you to ReSharper’s unit-test runner.

(The ReSharper test runner is also available for free as a separate download, if you don’t want to buy the full-fledged ReSharper.)

Now, why would the world need another unit-test runner? There are already so many ways to run tests. There’s the NUnit GUI, and the NUnit console runner. You can (and I have) write a rakefile that builds your solution using MSBuild and then runs the NUnit console, set up a Tools menu option to invoke it, and bind a keystroke to it. You can install TestDriven.NET. (You could even pay a lot of money for Microsoft’s test runner, although it doesn’t actually let you run the tests.) Don’t these cover just about every possible option?

Well, yeah. But ReSharper’s test runner is shiny. And being an IDE add-in, it manages some nice integration. Let’s take a tour.

Running all the tests

I’ve ranted about this before, so let’s start with the number one most basic feature of a testing tool: running all the tests.

Yes, ReSharper can do it, and it’s easy. The best way to run all the tests is to bind a keystroke (we use Ctrl+Shift+T) to the ReSharperAddIn25.UnitTestRunner_RunAllSolution command. Then, any time you hit Ctrl+Shift+T, it will automatically build your solution and run all the tests, showing the green (or red) bar as it goes.

If you don’t want it to be that easy, you can also go to the ReSharper menu > Unit Testing > Run All Tests from Solution. There are a couple of other options in the Unit Testing menu, but I ignore them, as they look like they do something other than run all the tests — and so far, we’ve done pretty well at keeping our NUnit tests fast.

Supported test runners

Out of the box, ReSharper’s test runner supports NUnit and csUnit tests. There’s also a third-party add-in to add mbUnit support to ReSharper UnitRun.

Integration

The ReSharper test-runner add-in really takes full advantage of being right there in Visual Studio.

• Dockable. The test-runner window is dockable just like all the other IDE windows, so you can tuck it out of the way. I dock it to the bottom of the IDE, in a tab-set with the Output window and the various Search Result windows. (If you put it in a tab set, and a different tab is visible when you run the tests, the test-runner window will come to the front, just like you’d want it to.)

• Key-bindable. As I noted above, it’s terribly easy to bind a single keystroke to mean “build everything, then run all the tests, and show me the results with a red or green bar”. So easy.

• Pays attention. When you make code changes and rebuild, all the icons in the tree turn into little question marks, so you can see that you haven’t run the tests yet. But they keep their colors, so you can still see which ones passed and failed last time around. Here are screenshots of the “freshly run” (check marks) and “after rebuild” (question marks):

  

  It’s even smart enough that, if you build your solution, but you haven’t actually modified any code, it won’t switch to the question marks. (I love this, because I’m always getting distracted by a conversation or something, and then can’t remember whether I just ran the tests or not.)

• Jump to the code. Two nice features here. First, if you double-click on a test in the test tree, the editor shows the code for that test. Secondly, if tests fail, the test results pane puts hyperlinks into the call stack, and clicking one of those hyperlinks will jump to that location in the editor.

  

• Gutter icons to run or debug a test. Wherever ReSharper notices a test method, it will show a little green-and-yellow circle in the gutter next to the code. If you click on that circle, you’ll get a dropdown menu with, among other things, an option to run that one test under the debugger. So if you want to put a breakpoint in a test and debug just that test, it’s easy.

  

Nothing in the ReSharper unit test runner is really groundbreaking, although the “jump to the code” features are pretty nice. It’s just that the features are all there, and they’re done well. If you do unit testing, give their test runner a try.

Welcome to day 4 of my 31 Days of ReSharper.

Here’s a feature you’ll notice as soon as you start typing: when you type an opening delimiter, ReSharper will type the closing one for you.

It’s a simple feature, but not a simple one to do well, and except for a bug that they introduced in 2.5 (and then fixed in 2.5.1), they do it well. Very seldom does it do the Wrong Thing.

This works for the following delimiters: {, (, [, ", and '. It doesn’t autocomplete generic syntax, though: < is not on the list.

Here’s a sample of it at work.

Starting out with an empty statement.
You type a method name…
and type “(”.
You type a subexpression…
and type “(”.
Oops. You meant “[”, not “(”. Backspace…
and type “[”.
Once you’ve typed the parameter…
you type “]”…
then you type “)”…
and then you type “;”.

They do the things right that need doing right: when you backspace over an opening delimiter, they remove the closing delimiter (assuming you didn’t type anything inside the parens yet); and when your cursor is before the closing delimiter and you type the closing delimiter, you don’t end up with two. This also applies to semicolons; when the cursor is before a semicolon, you can type a semicolon, and you won’t get two. You can just type normally, without having to hit the right arrow all the time.

They’re even smart enough to make it work inside arbitrary nesting: if you type the opening delimiter and the closing delimiter is already there, they don’t add it. There’s got to be some guesswork involved at some point, but I don’t remember it being wrong enough to notice.

Note: When you type {, you automatically get the matching } — meaning, if your intent is to put braces around a block of code, the matching delimiter gets in your way. Instead, you can use Surround With to add the braces around the current selection. The shortcut for adding braces is Ctrl+Alt+J 8. (Ctrl+Alt+J pops up a menu, so you don’t need to memorize the “8″ part.)

(Update: Ilya, one of the ReSharper developers, notes that you can have ReSharper add the closing brace when you hit Enter, instead of right away, which would make it easier to simply type braces around a block of existing code. Thanks, Ilya!)

This is a footnote to my article ReSharper survival guide, or, What’s up with my keybindings?, part of my 31 Days of ReSharper.

Welcome to day 3 of my 31 Days of ReSharper. (This is actually Saturday’s episode, but I’m posting it Friday evening because I’ll be out of town on Saturday.)

ReSharper is awesome. But if you’re going to use it — especially version 2.5.x (the latest version at this writing) — you need to read this Survival Guide first.

See, Visual Studio is full of keyboard shortcuts. ReSharper changes a significant number of them. And you need to know what changed and how to deal with it.

ReSharper 2.0 just silently hijacked your key bindings. ReSharper 2.5 asks nicely whether it’s OK for it to hijack your keybindings, the first time you use each keystroke; but it gives you no way to go back and change your answer — which is almost worse, because you could end up stuck without a good way to access some of ReSharper’s best features.

So before you start using ReSharper, you need a Keybinding Survival Guide. This is it.

Surviving ReSharper’s politeness

Really, there are only two things to worry about. One is the changes in high-traffic shortcuts, of which there are only a few; I cover them below. The other is the ReSharper Shortcut Conflict dialog.

As I noted above, ReSharper asks nicely whether it can take over any given shortcut. The problem is, it asks you the first time you use that shortcut, at which point you’re almost certainly in the middle of actually doing something, and in no mood to answer a silly question. Add in the fact that there’s no undo for whatever answer you give, and that they don’t even tell you what other key you should use instead, and you’re left with a pretty lousy user experience.

(Don’t get me wrong. ReSharper is an awesome tool. You just have to get past this dialog box before you can start using it.)

Based on my own experience, I think your best bet is to accept all of ReSharper’s shortcuts. Then you can either learn the new shortcuts for anything that changed, or go back in and re-map anything you can’t live without. And you can tell ReSharper to quit interrupting you with this silly dialog box.

So after you install ReSharper, I suggest opening up a solution, putting the cursor in a parameter list somewhere, and hitting Ctrl+Shift+Space. The “ReSharper Shortcut Conflict” dialog will pop up.

Leave the setting at “Use ReSharper command”, check the “Apply to all ReSharper shortcuts” checkbox, and hit OK.

And there you go. One problem survived: it won’t be bugging you again.

Now all you have to do is learn the keystrokes that changed.

The changed keybindings, part I: High-traffic keys

I did the research, so you don’t have to. Here are the keystrokes you need the most:

• Ctrl+Shift+Space no longer brings up Parameter Info. Use Ctrl+P (ReSharper’s enhanced parameter info) instead. It’s better anyway — especially when you’re facing Death By Overload in System.Drawing.
  • Ctrl+Shift+Space is now a variation on Ctrl+Space, which I’ll discuss later in the month when I talk about the Ctrl+Space family.
• F12 (Go to Definition) and Ctrl+F12 (Go to Declaration) (what’s the difference, anyway?) are replaced by Ctrl+B. You can also use Ctrl+Click.
• Shift+F12 (Find References) is now Alt+F7 (Find Usages). Usually they found alternate shortcuts that were better than the originals… obviously not in this case. Honestly, F7?
  • F12 and Shift+F12 now step forwards and backwards through the errors and warnings in a document.
• Ctrl+Shift+R to record a temporary macro, and Ctrl+Shift+P to play it back, are no longer available. This one hurts; I wish they’d kept them as Ctrl+Alt+Shift+R or something.
  • Ctrl+Shift+P is now Parameter Info - Go to Previous Signature.
  • Ctrl+Shift+R is now Refactor This, and is the main reason I’m not too upset about losing the keystroke for recording macros. You’ll use this far more often than macros, trust me.

Part II: Other notable changes

Here are some other things that most people probably don’t use every day, but that are still significant enough to be worth noting.

• Some Ctrl+key prefixes (Ctrl+B, Ctrl+D, Ctrl+E, Ctrl+F1, and Ctrl+W) are now commands in their own right, not prefixes. For example, Ctrl+B Ctrl+C used to clear bookmarks, but Ctrl+B is now Go to Declaration, so multi-key Ctrl+B commands are no longer available. Visual Studio already provides alternate keystrokes for many of these (e.g., many of the Ctrl+B commands are also available through Ctrl+K), and ReSharper adds its own alternate keystrokes for a handful of them.
  • Ctrl+B is now Go to Declaration.
  • Ctrl+D is now Duplicate Text.
  • Ctrl+E is now Go to Recent Files.
  • Ctrl+F1 is now Help - How Do I (formerly Ctrl+F1 H).
  • Ctrl+W is now Select Word / Extend Selection.
• If you used Ctrl+Alt+Down Arrow to show the MDI list (same as clicking the down arrow at the top right of the document area), that keystroke is no longer available.
  • Ctrl+Alt+Up Arrow and Ctrl+Alt+Down Arrow are now Go to Previous Occurrence and Go to Next Occurrence.
• Ctrl+/ to go to the Find combo (did anybody actually use that?) isn’t there anymore. Ctrl+D still brings it up, but only if the focus isn’t in the editor window.
  • Ctrl+/ is now Comment / Uncomment Selection.
• F7 (View Code) and Shift+F7 (View Designer) are now just F7 to toggle between the two. Yay!
• F6 no longer builds the solution. Use Ctrl+Shift+B instead.
  • F6 is now mapped to a command simply called “Move”. I don’t know what it does; I couldn’t get it to come up enabled. (Update: Maruis explains ReSharper’s F6 Move command. Thanks, Maruis!)

Those are the short lists. I also made a complete list of every keybinding that changed when I installed ReSharper. This list only shows the keys that were changed or removed, not the ones that were completely added. Even so, it’s a long list. But if you find a keystroke that used to work and now does something weird, check out the full list. (Note that I had Ctrl+Shift+T bound to a macro to run tests; I think that Visual Studio binds it to something else by default, Swap Words or something weird like that.)

Welcome to day 2 of my 31 Days of ReSharper.

So I talked about the grays in day 1. The next thing you’ll notice, after you install ReSharper, is the color bar.

Whenever you’re editing a source file, a color bar will appear next to the vertical scroll bar. There’s a little box at the top, which can be green, yellow, or red. The ReSharper docs refer to this whole assemblage as the “marker bar”.

Wherever there’s a line of code with gray in it, ReSharper shows a little yellow tick mark. Wherever there’s a line of code with compiler errors, ReSharper shows a red tick mark. These are proportionally spaced throughout the bar (the color bar doesn’t scroll; its height represents your entire source file), so if you’ve got a source file with a lot of lines of code, the tick marks will be spaced closer together.

The little box at the top is there to quickly show you the status of the entire file. If there are any compiler errors (red ticks in the color bar) in this source file, the box is red. If there are no errors, but there are ReSharper warnings (yellow ticks in the color bar), the box is yellow. The object of the game is to make the box green.

Of course, it doesn’t stop at pretty colors. ReSharper is there to help you code, and so it does. You can hover over one of the tick marks to see a hint, describing the problem. You can also click on a tick mark, which will position the cursor on the line of code in question.

Better yet, you can use F12 to move to the next problem in the file. (Shift+F12 moves to the previous problem.)

The only downside to this feature is that it’s per-file. There’s no easy way to see whether the entire project (or solution) has a green box, and pretty soon you’ll start wishing for that feature!

Here’s a tip: you can multi-select in Solution Explorer. So click on the first source file in your project, then Shift+click on the last one, and press Enter. This will open all your files in the editor, each in its own tab. Then start closing files (Ctrl+F4), keeping an eye on the color box. As soon as you hit one that’s not green, it’s time to get to work.