Twitter LinkedIn Github

JetBrains

Writing plug-ins for ReSharper: Part 1 of Undefined

ReSharper does a lot of things, but as they say, you can’t please all the people all of the time. However, one the great things about ReSharper is that it is quite extensible and there are already quite a number plug-ins available. Some of the better known ones are:

- StyleCop for ReSharper by Howard Van Rooijen

- TDD Productivity Plugin by Eric Hexter

- ReSharper Test Runner for MSpec by Alexander Groß 

and of course there is also the repository of plug-ins available from the JetBrains site, where many of these are located.

Now I’m no expert on writing plug-ins for ReSharper, and the authors of the previous ones leave the bar quite high, but seeing that I actually now have the time to play with them, I’ve decided to do so by sharing my experiences with you in a series of blog posts.

The ReSharper API is pretty extensive and can be overwhelming as I’ve been discovering, so I want to try and take it slowly. This might mean that at times, the code is not always complete and might be missing a few checks for example, but will come in due course.

Everything that I’ll cover applies to version 5.0 which is currently in Beta. There have been some changes from previous versions so if you’re working with 4.5 some of the code might not work.

 

The First Plug-in

I was initially intending to write a useless plug-in for the first demo that didn’t do much, but after talking to Orangy (aslo known as Ilya) who commented on a tweet Jeremy Skinner had posted a few days back:

1</a>

we decided to use it as the first sample.

I’m going to build up the sample over the next few series of posts, so the initial solution is not the ideal one or complete, but it will help introduce a few core concepts. Ideally this feature should be implemented as what’s known as a QuickFix but we’re first going to do it as a ContextAction.

 

ContextAction

So what exactly is a Context Action? It’s actions that can be applied based on the context (the name is quite descriptive). They shows up as items in a popup menu which is invoked using Alt+Enter (don’t use the mouse for this…it’s very unproductive).

2

What we want to do in this first version of the plug-in is to write a new action that makes methods that are public and not declared virtual, virtual, something NHibernate users would appreciate greatly. As mentioned previously, in this first version we’re going to add a context action.

1. Creating a plug-in assembly

ReSharper plug-ins are assemblies that are located in Plugins folder (by default %programFiles%\JetBrains\ReSharper\v5.0\Bin\Plugins). Each plug-in is in it’s own folder and doesn’t require any further registration. Therefore the first step is to create a class library which will host our context action.

2. Creating the Context Action Skeleton

In order to create a context action, we need to implement the IContextAction interface. This interface has one method IsAvailable which indicates to us if that particular action is available given the context, and a property of type IBulbItem[] which contains a series of bulb items. Each IBulbItem in turn has a property Text which is the text that appears next to the item in the context dropdown, and an Execute action, which is what happens when the item is selected. So as we can see, a context action can consist of more than one bulb item. An added benefit to this decoupling is the re-usability of bulb items. By implementing IBulbItem, we can potentially use it in more than once place (obviously if it makes sense).

Many times however, we only want one bulb item per action, and to somehow simplify the process, we can inherit from the BulbItemImpl class. This class defines an abstract Text property that represents the text of the bulb item, and also has an ExecuteTransaction member which is where our code is executed. We’ll see the difference between this method and Execute shortly.

 

  1. public class MakeMethodVirtualContextActions: BulbItemImpl, IContextAction
  2. {
  3.     protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress)
  4.     {
  5.         throw new NotImplementedException();
  6.     }
  7.  
  8.     public override string Text
  9.     {
  10.         get { throw new NotImplementedException(); }
  11.     }
  12.  
  13.     public bool IsAvailable(IUserDataHolder cache)
  14.     {
  15.         throw new NotImplementedException();
  16.     }
  17. }
    18. </ol></div></div></div>

     

     

    Before implementing any of the methods, there’s one thing we need to do. ReSharper requires that context action have a constructor with a parameter that implements a IContextActionDataProvider. This parameter is actually useful to use to provide information about the context as we’ll see shortly. Therefore, we need to add a constructor to the previous code (lines 6-9). Since our action is only for C#, we will use a ICSharpContextActionDataProvider. We then save this provider for later use (line 3). What we’re effectively doing here of course is nothing more than dependency injection. The plumbing (passing in the correct provider) is taken care of for us by ReSharper.

     

    1. public class MakeMethodVirtualContextAction : BulbItemImpl, IContextAction
    2. {
    3.     readonly ICSharpContextActionDataProvider _provider;
    4.  
    5.  
    6.     public MakeMethodVirtualContextAction(ICSharpContextActionDataProvider provider)
    7.     {
    8.         _provider = provider;
    9.     }
    11.     protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress)
    12.     {
    13.         throw new NotImplementedException();
    14.     }
    15.  
    16.     public override string Text
    17.     {
    18.         get { throw new NotImplementedException(); }
    19.     }
    20.  
    21.     public bool IsAvailable(IUserDataHolder cache)
    22.     {
    23.         throw new NotImplementedException();
    24.     }
    25. }
      26. </ol></div></div></div>

       

      3. Defining Availability

      The next step is to define when our action is available. In order to do so, we need to implement the IsAvailable method. In our case, we want to convert methods that are public and not virtual, to virtual. We therefore need to identify methods that are public and not virtual. We also need to filter out static methods. In order to get access to the current context we’re in, we can use the provider we injected in via the constructor. The provider has a GetSelectedElement method which corresponds to the element the caret is on. Since we’re interested in a method, we can invoke this function, requesting back a method declaration. If the caret is in the context of a method (i.e. header, body), it will return this information. If it’s not, it will return null.

      If we have a valid method declaration, the next step is to find out if it is public. We do that by invoking GetAccessRights [In later series we’ll see that further checks are necessary here]. If it is public, we then need to check whether it is a static method, an override or already virtual. Based on that, we return true or false, indicating whether the action is available in the current context.

       

      1. public bool IsAvailable(IUserDataHolder cache)
      2. {
      3.     var item = _provider.GetSelectedElement<IMethodDeclaration>(false, true);
      4.  
      5.     if (item != null)
      6.     {
      7.         var accessRights = item.GetAccessRights();
      8.  
      9.         if (accessRights == AccessRights.PUBLIC && !item.IsStatic && !item.IsVirtual && !item.IsOverride)
      10.         {
      11.             return true;
      12.         }
      13.     }
      14.     return false;
      15. }
        16. </ol></div></div></div>

         

        4. Performing the action

        When the action is available and the user selects it, what we need to do is make the method virtual. This is done in the ExecuteTransaction method. Since we are going to modify the code, we need to make sure that the file is writable. Normally this would be done by invoking a call to a method named EnsureWritable. However, inside the method ExecuteTransaction, this is done for us, so we don’t have to worry about it. This is one of the differences between ExecuteTransaction and IBulbItem.Execute.

        So how do we go about modifying code in ReSharper? Well remember that refactoring code is ReSharper’s daily bread. It’s what it does. As such, there’s a ton of infrastructure in place to allow us to do modify code easily. In fact, making a method virtual is as easy as calling a method, as shown below.

        1. protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress)
        2. {
        3.     var method = _provider.GetSelectedElement<IMethodDeclaration>(false, true);
        4.  
        5.     if (method != null)
        6.     {
        7.         method.SetVirtual(true);
        8.     }
        9.  
        10.     return null;
        11. }
          12. </ol></div></div></div>

           

          5. Testing the plug-in

          The only thing left to do is test that it works (writing unit tests for plug-ins is something we’ll cover in the future). One option is to copy the assembly to the plug-in folder for ReSharper and restart Visual Studio. However, in order to be able to debug it, what we can do is set the project properties to start an external program, which is non other than devenv.exe, and pass as parameter to it /ReSharper.Plugin <Path_to_Plugin_Assembly>, instructing ReSharper to load a specific plug-in.

          How does ReSharper know which classes in the assembly are context actions? The easiest way is to decorate these with the ContextAction attribute

           

          1. [ContextAction(Group="C#", Name = "MakeMethodVirtual", Description = "Adds context action to make methods virtual")]
          2.     public class MakeMethodVirtualContextAction : BulbItemImpl, IContextAction
          3.     {
          4.   
            5. </ol></div></div></div>

             

            This information is also what appears under ReSharper –> C# –> Context Actions

             

            3

            Now all that’s left is to try it out. Write a new class, add a few methods and check to see it’s all working correctly.

             

            4

            Public static method (not available)

             

            5

            Private method (not available)

             

            6

            Public method (option available)

            What’s next?

            In this first part we’ve seen the basics of writing plug-ins for ReSharper. In the next blog post, we’ll extend the example to also include properties and we’ll change it to be a QuickFix as opposed to a context action. This means that we’ll get some nice highlighting by ReSharper telling us something can be changed (similar to when you have something named incorrectly for instance), thus being more *in your face*.

            There’s so much more to see than what’s here, and gradually we’ll drill more into each of the different areas, examining parameters, return values, etc. Until then, Happy ReSharping (did I just coin that? Too lame?)