My five favorite features in ReSharper 4.5
With the recent release of ReSharper 4.5, many productive features have been added to this already great product, such as performance and memory usage improvements, solution-wide code inspections, VB9 support, and many more. I’ve been using ReSharper as my pair programmer for many years as it helps me to enhance my C# refactoring whenever I overlook some portions of code I’m writing, as well as to manage my unit tests. In this post, I will concentrate on sharing with you my five most favorite new features in ReSharper 4.5.
1. Find dependent or referenced code
Using this new feature, you can find dependent or referenced code at either a project or file level. Before going forward with this feature, it is important to understand what is meant by “dependent code” and “referenced code”. Both of these terms have to do with dependencies/coupling. When you ask ReSharper to tell you the dependent code at the project level, you are actually asking it to tell you which other projects (or assemblies) are dependent on that specific project. On the other hand, when you ask ReSharper to tell you the referenced code at the project level, you are asking it to tell you which other projects (or assemblies) that specific project depends on. For example, suppose the following UML class diagram:
In this scenario, I have four different assemblies: one client console executable (Client), and three class libraries (Provider, Utilities and SecurityManager). Our Client executable references the three other assemblies because it’ll make use of their services. Those references were created when I asked Visual Studio to add me the references for those three projects at the project level. Now, if I were to ask ReSharper to tell me the dependent code at the project level (which means that you right-click on the Client project in the Solution Explorer, and then click on the Find Dependent Code contextual menu item), a message box will appear telling me that “Code dependent on project ‘Client.csproj’ was not found”:
This is normal, because according to our class diagram above, Client has an afferent coupling of zero (Ca = 0).
Afferent coupling(s) is the number of class(es) outside this component (i.e., Client) that depend on classes within this component (i.e., Client).
On the other hand, if we were to ask ReSharper to tell us the referenced code at the project level (for Client), by this time clicking on the Find Referenced Code contextual menu item, you will get the following results:
In this case, ReSharper is telling us the types which are being used in that specific project (Client), even .NET types and assemblies like mscorlib.dll. Since the Client class has a positive non-zero efferent coupling (Ce > 0), we actually get a result.
Efferent coupling(s) is the number of classes inside this component (i.e., Client) that depend on classes outside this component (i.e., Client).
These results could look daunting at first sight, but that’s because the results window is showing too much information. All you have to do to get a more simplistic and lighter view of the results is simply to click on the Filter Usages button (that’s the one surrounded in red in the screenshot below) and unselect the Show Attribute Usage from the proposed choices, as you don’t really care that you’re depending on the AssemblyAttribute class for example. Furthermore, you should also click on the Merge Occurences on the Same Line button (that’s the one surrounded in green in the screenshot below), so that you eliminate some of the redundancy usages on the same line. Finally, choose an appropriate view to group your results (in this case, I have chosen to group the results by Namespaces and Types. That’s the one surrounded in blue in the screenshot below). This will give you the following (much more compact) result view:
NOTE: If you only reference external projects or assemblies in a project without actually using the public types or members in those external dependencies, ReSharper will not tell you that you are actually referencing those dependencies. This is pretty slick, as you can visually know whether or not a reference is unnecessary, and thus proceed with its removal.
Ah, much better! And you know what? That’s pretty much right, because the Client class is actually using those classes (Provider, SecurityManager and Utilities), as shown in the screenshot below:
At the file level, you only get to ask ReSharer to tell you the referenced code, through the Find Referenced Code contextual menu item. In this case, the results will include any type being used in that file. Suppose for example that in the SecurityManager class, you’re using an instance of a Logging class to log some errors in a few critical methods. In that case, the results will include the Logging class, as it is a type being referenced in that file. So far, so smart.
2. Go to implementation (Ctrl+Shift+Alt+B)
This one is pretty simple and very much useful. Suppose you have the following class hierarchy:
In the previous versions of ReSharper, you couldn’t ask the tool to directly tell you which concrete classes derived from an abstract type. Instead, you had to select the abstract type and ask it to tell you the derived types (or inheritors) through the Ctrl+Alt+B shortcut, which would give you a list of all the types deriving from that abstract type…even if those derived types were abstract themselves. This was pretty frustrating when you had a hierarchy with a lot of abstract relationships amongst types, as it was the case in one WCF-driven project I was involved in, because you would lose a couple of seconds filtering out the concrete types from the abstract ones in the results list. Well, that’s an old story because now you can get the list of all the concrete types (or implementation types) directly from a new shortcut: Ctrl+Shift+Alt+B, or through the “Go to implementation” command in the “Go to” navigation menu. For example, if you asked ReSharper to tell you the concrete classes for IProvider, it’ll tell you that MembershipProvider and SecurityProvider are the only ones. It will ignore ProviderBase, as it is abstract. Well done!
3. Naming styles
With ReSharper 4.5, we get more flexibility in the naming style department. You can apply either a common naming style for both C# and VB code, or set one differently for each of them. It’s up to you. The UI interface to manage the naming styles is pretty simple. Here, for example, is the Naming Style window pertaining to both C# and VB:
So you get a list of predefined styles out-of-the-box which might suit most of your basic needs. The flexibility offered by these features comes in handy when you want to create new styles, modify some existing ones, etc. Suppose you want to add a new naming style for private fields only, and make them prefixed by an underscore. You would simply click on the “Add” button under the User defined naming rules panel, which will show the following window:
All I have to do is select the affected entities, which in this case would be “Field” and “Readonly field”. Then I would specify the access modifiers, which sould be Private and Protected. Following that, I will specify the underscore as the name prefix and tick the lowerCamelCase naming style, as to be follow the .NET design guidelines. Finally, I would set the rule description to something explicit, such as “Private fields”. That’s it! Now I can save and share the code style file with my team.
4. Collapse all project nodes (in Solution Explorer)
Suppose you have the following project structure in Solution Explorer:
This would be a very typical folder structure in an ASP.NET MVC project, for example. Every time you collapse the node associated with the SecurityManager project, and you expand it later, you will see the same result as above. This can be very frustrating when you have dozens of projects with their child nodes expanded in a similar way in Solution Explorer, and God forbid you have also expanded the References node, because it tends to visually pollute the Solution Explorer. ReSharper 4.5 introduced a new feature that allows you to definitively collapse a node, be it a folder or the project node itself, so that the next time you expand the root node, the previously collapsed node stays closed! This might sound like nothing, but have you ever calculated how many seconds you probably were wasting trying to navigate the Solution Explorer when you have a multitude of projects with folders, or solution folders, all open at the same time even though you don’t really need them to be? That’s not being productive. That’s not being professional.
So here’s the trick: when you’re done with one node and you need to collapse it for good, simply right-click on it in the Solution Explorer, and choose “Collapse All”. This would permanently collapse the node until you explicitly expand it again. For example, if I decide to execute this “Collapse All” command on the Users folder, then each time I expand the SecurityManager node, the Users folder will stay collapsed, until I explicitly expand it. In my opinion, this should’ve been a standard option for Visual Studio. Good thinking once again!
5. Inline field (Ctrl+Alt+N)
The fifth of my favorite new features in ReSharper 4.5 is the possibility to inline a field. As to tweak the original Inline Temp refactoring definition to suit this one:
You have a field that is assigned to once with a simple expression, and the field is getting in the way of other refactorings. Replace all references to that field with the expression.
I think that little definition sums it up well what Inline Field does. Simply highlight the field, then hit the Ctrl+Alt+N shortcut, and you’re done. Here’s a last example. Suppose you have the following class definition:
As you can see, the someString field is used only once in this class, which is pretty much useless. In that case, I will place my cursor on it, then hit Ctrl+Alt+N to have it inlined:
And that’s it! Now through all the code, the field’s expression will be inlined. This was a simple scenario, but I’m sure you can think how useful this refactoring could be in your codebase.
[UPDATE: 2009-04-14] The Inline Field refactoring also works to inline methods and properties, not only fields! This is very sweet. They should call this command Inline Construct as it doesn’t just inline fields.
But there’s more!!!
Of course, my list of favorite new features in ReSharper 4.5 isn’t the whole story behind this new release. For a complete list of new feature in ReSharper 4.5, I’ll invite you to review its What’s New in ReSharper 4.5 features page. ReSharper is getting better and better through each release, and I can’t wait to see what the team is going to include in the 5.0 release. But meanwhile, if you haven’t upgraded to this new version, I urge you to do so. Plus, the upgrade is free if you’re already a ReSharper 4.x licensee, so you really have no excuse. And if you’re not currently using ReSharper at all, then I hope that the following post has incited you to ask your tech lead or manager to get a license for it (I would suggest to start with the trial, then demo it to your group). I’ll also invite you to read my post on The Case for ReSharper in the Enterprise which might give you some pointers on the necessity of this tool in your development toolbox.
Similar posts you might be interested in reading:
- Avoid calling a virtual or abstract method from a constructor in C#…especially in VB!
- Why you should use static read-only fields over constants when dealing with strings
- Mapping a shortcut to execute unit test in current context with ReSharper
- ReSharper 3.1 Released and Getting Better Than Ever!
- The Case for ReSharper in the Enterprise
- Using the “Source Control – Team Foundation” toolbar to perform common TFS operations on the current document within Visual Studio
- C# Search: The .NET developer search engine






Tom Kostromin:
Wow nice tips, thanks for sharing. Reshaper delivers!
June 30, 2009, 7:37 amSJ:
good one.
July 23, 2009, 2:40 pm