Resharper

Finding typos with ReSharper Command Line Tools, ReSpeller and Cake

TPodolak, ,

1. Introduction

I tend to do a lot of typos when I write a code and I mean a lot. This is quite annoying for me so I decided to somehow automate the process of finding the spelling errors during the build. My first thought was to use some kind of Roslyn analyzer, however, I failed to find any working one. This is why I decided to give a try to ReSharper Command Line Tools (also known as CLIT) combined with ReSpeller plugin. For those who don’t know, ReSharper Command Line Tools is set of tools which allow you to use ReSharper inspections without Visual Studio

2. First attempt

This was supposed to be a rather straightforward task because according to documentation command line inspections support extensions out of the box. The example presented in the help page was supposed to be the perfect one for me

Unfortunately, it turned out that extensions support is broken for some time and it wasn’t working for me either (tested on Command Line Tools version 2017.2).

3. The workaround

Even though extension support is not working as expected I was able to make it work with some workaround. The workaround itself is a combination of helpful tips taken from this YouTrack issue. Long story short, we have to manually install the plugin and then force ReSharper to use it. Assuming that you have command line tools installed this can be achieved in following way. First of all we have to get our hands on ReSpeller plugin. We can install it using NuGet but before you do it, remember to add additional feed to nuget.config file.

The feed url can be found in the ReSharper’s option page and for version 2017.2 it is

Having our NuGet sources updated we can retrieve the package using following command

The next step is to copy ReSpeller’s DLLs from following folders

directly to CLIT tools folder – JetBrains.ReSharper.CommandLineTools\tools. What is more, ReSpeller comes together with dictionary files which also have to be copied to the tools folder. This time, however, we have to copy entire etherealcode.respeller.4.6.9.2\EtherealCode.ReSpeller\lib\net45\dic directory, not only its content. The very last thing is to make ReSharper aware of the plugin, in order to do that we have to find EtherealCode.ReSpeller.JetMetadata.sstg file. The file itself doesn’t come together with the package but it is generated by ReSharper during plugin installation. So the easiest way of getting that file is to install ReSpeller as a ReSharper plugin in Visual Studio and then copy the sstg file to tools folder. After all that work now if you run

(note lack of -x switch) you will see spellcheck inspections in output file.

4. Cake integration

Doing all that stuff manually is error-prone and time-consuming and of course, I wanted to have the spellcheck up and running on the CI server, that is why I’ve also automated all above steps with Cake build script. The core concept is to use ReSpeller and ReSharper Command Line Tools as so-called “Cake tools” to run the inspections and Cake.Issues and Cake.Issues.InspectCode plugins for analyzing the output file.
Adding tools and add-ins is straightforward we just have to add following lines on top of the build file.

We also have to add nuget.config file to our build directory in order to point Cake to ReSharper feed (you could also modify the global nuget.config but I don’t want a build process to change the behavior of entire system)

Before calling InspectCode.exe we have to make sure that all of the files and folders exist

Having all of the items in place now we are ready to run the actual spellcheck and verify the results

As you can see I start InspectCode.exe process with a bunch of parameters. Once the process returns successful exit code I can go ahead and process the results thanks to ReadIssues and InspectCodeIssuesFromFilePath methods provided by the add-ins. Because of the fact that ReSharper can produce a ton of inspections I only care about the ones which are typos. Simple and very naïve LINQ query can do it for me

If any typos were found I just throw exception with a listing of all the issues. Note that I aggregate all the issues into one big message because if you have lots of typos (just like I do) rendering them can take some time

The source code for slightly enhanced version of that script can be found here

Finding typos with ReSharper Command Line Tools, ReSpeller and Cake

Generating PDB files with Resharper

TPodolak

The majority of the libraries developers use in their projects these days are open source. So in case something crashes inside third party library or you just want to know how it works, it is possible to get the PDB files from Microsoft Symbols Servers and debug it. If for some reasons PDB cannot be found on the servers, you can always grab the source code from GitHub and add to your project manually. Unfortunately when you use commercial libraries, it is impossible to do any of the previous steps. Luckily with Resharper you are able to generate PDB files from assembly and use it later in Visual Studio to debug it.
Let’s assume we would like to generate PDB files for EntityFramework. First of all, we have to locate EntityFramework assembly in Assembly Explorer. Go to Solution Explorer, RMB click on assembly you are interested in and select View in Assembly Explorer.
ViewInAssemblyExplorer
In Assembly Explorer once again RMB click on EntityFramework and select “Generate Pdb…”
GeneratePdbFileMenu
In the opened window, select the destination folder for the files.
GeneratedPdbsOption
Once you click “Generate“, Resharper will process the assembly and generate PDBs.
PdbGenerated
Once the files are generated we have to tell Visual Studio to use them. In order to do that, run the app and stop the execution with some breakpoint, then go to Debug->Windows-> Modules, locate EntityFramework.dll, click it with RMB, select “Load Symbols” and choose file(s) generated by Resharper.
LoadSymbols
A this point we have PDB files ready but we are not able to set any breakpoint as we don’t have source code of EntityFramework. Fortunately Resharper once again saves the day as it is able to navigate to decompiled sources. Just make sure that your settings (Resharper->Options->External Sources) are the same as in the picture below
decompile
and you can navigate to external libraries’ source code just like they were in your project. The very last step is to disable “Enable Just My Code” option in Tools->Options->Debugging->General
JustMyCode
and from now on you can debug the external library
DbContextDebugging

Generating PDB files with Resharper

Resharper – localizable string literals

TPodolak, , ,

Everyone who has ever tried to create multilingual application knows, that this is very tedious task. The most repetitive work is usually moving hard-coded strings to resource files. Fortunately with Resharper this is definitelly less painfull than usuall.
In order to point out localizable parts of application , it is necessary to decorate classes with System.ComponentModel.LocalizableAttribute. LocalizableAttributeHowever, usually we want to localize an entire program, so more universal solution is to set appropriate project configuration in properties window. To bring up this window, select project file and then press F4 button.
PropertiesWindow
From now on, Resharper shows warnings indicating that our hard-coded strings might be moved to resource file. Pressing ALT+ENTER on these strings will bring up the context menu action, where new option – “Move to resource” is available.
MoveToResourceContextAction
Choosing this option will bring up the “Move to Resource” window. However if we do not have any resource files in our project, we will get this message.
NoResourcesFound
In order to create these files, right click on project and choose Add->New Item. Now, select Resource.resx file and name it for example LocalizableStrings.resx.
AddingsResource
In this resource file we will store values for our “default language”. Supporting more languages require us to create additional LocalizableString files with appropriate LETF tags suffixes.
Allfiles
Now, we are able to move our hard-coded string to resource files.
MoveToResource
aftermove
By default Resharper adds hard-coded strings to default resource file, so we have to specify values for localizable string for other languages. In order to do that, first navigate to resource entry in LocalizableStrings.resx file by holding CTRL and clicking property “Program_Main_This_is_localizable_string”
GoToProperty
overriden
and then press ALT+ENTER and choose “Override ‘PropertyName…'”. This operation brings up “Edit Resource” window where You can easily navigate between resource files and update given resource property
EditResourceDialog
Resharper not only is able to move strings to resource files but also can use existing ones. This basically means that if we use hard-coded string which already has been added to resource file, Resharper will suggest to use predefined resource
localizable string

Resharper – localizable string literals

Resharper – “Go to Everything”

TPodolak, ,

In Resharper 8 JetBrains introduced new command called “Go to Everything”. You can use it by hitting the CTRL + N keys (CTRL + T with Visual Studio keyboard shortcuts layout) This command is basically combination of three features known from previous versions of Resharper, namely: “Go to Class”, “Go to Type” and “Go to Symbol”. Most common usage of this functionality is just to search classes, properties or functions.
Go to Everything
However not everyone knows, that we can narrow down search criteria and find methods or properties in given class
Go to Everything
What is even more interesting, is the fact that it is possible to go to specific line in searched type
Go to Everything

Resharper – “Go to Everything”

Resharper – annotation attributes

TPodolak, , ,

1. Introduction

I think one of the most important features of Resharper is on-the-fly code quality analysis. Basically, every time Resharper finds possible pitfall in code, it indicates this with appropriate warning. The most common warning is “Possible System.NullReferenceException”. You can easily reproduce it by writing this code

singledefaultwarning
As you can see R# is able to figure out, that LINQ SingleOrDefault function can return null. However there is no warning if we try to do something like that

So it got me thinking, how Resharper recognizes whether or whether not to show warnings. It turned out, that it uses annotation attributes, which describe behavior of functions, properties, classes and interfaces.

2. Source code annotations

In order to use these attributes we have to place them in our project. First of all, let’s create Annotation.cs file and then copy default implementation of annotations into this file. The default implementation can be found in Code annotation option (Resharper->Options->Code Inspections->Code Annotations) under the button “Copy default implementation to clipboard”.
resharperOptions
annotationoptions
From now on we can decorate our functions with e.g. CanBeNull attribute

and we will get warning if necessary
annotation attributes
Of course there are a lot more of attributes to use. My favorites are:

  • StringFormatMethodAttribute
    annotation attributes

  • PathReferenceAttribute
    annotation attributes

  • NotifyPropertyChangedInvocatorAttribute

    • annotation attributes

3. External code annotations

In case we do not have access to source code, we still are able to use annotation attributes. However we have to define annotations in xml configuration file. Let’s say we want to decorate NHibernte’s SaveOrUpdate function with NotNullAttribute. First of all we have to create xml file with appropriate declaration (This is standard XML Document Comment file. You can read specification here and here.)

Having prepared configuration file, we need to place it in appropriate location in order for Resharper to use it. It can be stored in

  • [ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name].xml
  • [ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name][Any name].xml.

So in my case the location is

After restarting Visual Studio, Resharper should load the file and show warning messages.
nhibernate

4. Generating initial XML annotation files

Creating xml annotation file for large library is very tedious task, fortunately Resharper have a hidden feature which can help us with generating initial xml file. First of all we have to run Visual Studio with /ReSharper.Internal parameter. In this mode we have an access to undocumented/hidden features of Resharper. Now, in the “Resharper” menu there is one additional menu item – Internal, where You can find Annotator submenu in which resides Annotate item.
annotator
Now You can specify for which dll Resharper should generate xml annotation file.
annotatorwindow
and after a while You should get complete xml declaration.
annotatorprogress
Please bear in mind, that Annotator is not official R# feature, so there is no guarantee that generating annotation files will succeed. Source code for this post can be found here

Resharper – annotation attributes