New CodeRush Plugin – Introduce Local (All Arguments)

The Motivation

I found this question on Stackoverflow

Essentially it breaks down to…

How can I refactor this….


…into this…


… in a single step.

The Plugin

This plugin allows you to extract all arguments of a method to new locals which are then placed above the method call.

  • Place your caret on the call to the method whose arguments you’d like to extract.
  • Hit the CodeRush\Refactor key (Ctrl+` by default)
  • Choose “Introduce Local (All Arguments)
  • You’re done.

And the Result


Where can I get this wonderful plugin?

As usual, the source code and binary for this plugin are available on github

Like many others, this plugin is listed on the CodeRush Plugins Site.

The CodeRush Community Plugin Site

I’ve recently been asked:

How come you’re putting all your plugins on GitHub? Have you abandoned the DXCoreCommunity site?

This post is an attempt to answer this question.

The Problem

The tech and structure underlying the existing DXCore Community Site is old and out of date. It’s an SVN repository hosted with Google Code. It’s a single repository that holds many plugins. The site is larger than I ever though it would be. We have over 100 plugins and their associated wiki pages and it’s “getting” out of hand.

Within the current structure, branching and merging is so much of a pain that I don’t think it’s been done in a very long time. Its actually an inertial barrier to making any changes at all.

With hind-sight, it should probably never have been created as a single repository of plugins. Rather it should have been an index to many repositories, each holding their own plugin project. However what’s done is done and porting 100+ projects out of a single SVN repository and into 100+ individual repositories (along with their various wiki pages and links between them) is a task that seems a little impractical to take on wholesale.

The other major pain point of the SVN based site, is it’s centralized nature. A single central repository means that it has a single central access management system.
ie Anyone who needs write access, needs to be given explicit write access. In addition there is no way to give access to only those parts of the project that make the most sense. Write access is site wide, or not at all. As the breadth of a project grows, so does this issue.

First Steps

The first step in solving any problem is to recognise it’s existence. In this case, I acknowledge: the community site is too big and unwieldy to manage properly, and it has been for some time.

The second step is to stop making it worse. If I can help it, I will not be adding any additional plugins to that site.

So how to move forward?

The Code

So far as the code is concerned, I’ll be doing what you have seen recently. Creating each new plugin within it’s own repository. Each repo will contain code, readme and releases (including binaries).

I will be using Git, because I believe I find it quicker, easier and more flexible than any other source control I have used before. The use of Git, along with isolating each plugin in its own repo, will make branching and merging much easier. This in turn will allow easier experimentation, and more innovation.

This means that there, will be many more repositories than before. This was always the case anyway, but the community site ironically didn’t do much to acknowledge the community outside it’s own walls. People already create plugins which are not a part of the site. They blog about them independently and even host them in different types of source control.

So in acknowledging that there are plugins beyond the community site, we justify the continuing need (perhaps a bigger need than before) for a site whose purpose is to provide a location for people to learn about the existence of such plugins.

The Community Site

This rise in plugin locations increases the need for somewhere to index them. Whilst I could repurpose the existing Community site, it’s worth noting that the single central access management system is as much of an issue with the wiki side of things as it is with the source code side.

The Community Site, or rather the tech that supports it, is not up to the task of providing a central location to locate useful plugins.

So we need a new community site which needs to be…

  • Somewhere where pages can easily be edited.
  • Somewhere that’s easy to backup.
  • Somewhere that’s easy for others to contribute to.

Can you see where I’m going with this?

Yup… I decided I decided to depart the shores of Google Code and set sail for the land of GitHub.

Hosting the site using Git has a lot of advantages:

  • Local Everything
    Local edits mean you can use a local editor and all the speed and other features that come with it.
    Local branching, merging and committing and merging, means you don’t need to reply on the server (or the speed of that server) to get almost anything done.
  • Push Technology
    Pushing your website to a server in the same way you push your code is awesome. It makes revision control easy and rollbacks (if they are needed) are completely painless.
  • Fork Me!
    The ultimate in open. Others can copy the entire site if they want, and make an even better index. Improvements can be offered back and absorbed without any permissions ever being allocated.

In addition there are particular advantages to hosting with GitHub

  • GitHub Pages
    A feature where a branch of a repository is treated as the source files of a website. This benefits from a backend system which compiles markdown into html.
  • Pull requests
    A feature where someone forks code and makes changes. Later they can request the original repo pull those changes back into said repo.
    This is entirely possible via email without GitHub, but much smoother with it.
  • Releases
    A feature where any tagged commit can be elevated to a release which then can have associated binaries and release notes attached.

The new community site will be a pure index. It will not be responsible for any plugin code. It will not be responsible for any plugin readme file. It will likely have to contain a basic description of each plugin and might list any given plugin on multiple pages according to it’s categorization. However the plugins will not be hosted on this site and the plugin’s authors will retain complete responsibility for them.

Not hosting the plugin code or binaries gives the new community site an advantage over the old one. Every linked plugin is equal in the eyes of the community site.

The site can link directly to:

  • Plugins in the Old Community site.
  • Plugins in my Github repositories.
  • Plugins in anyone else's Github repositories.
  • Plugins in any public repositories anywhere. (Bitbucket, Google Code, GitHub, CodePlex etc.)
  • Plugins on people’s blogs or other websites.
  • Plugins with no source available.
  • Plugins on the Visual Studio Gallery
  • …without granting any of them special treatment because of their local status, because none of them will be local.


    The previous community site used the MIT licence. this was felt to be a lowest common denominator. It was understood that plugins hosted on the site were essentially anything as long as the original author was recognised. However not everyone wanted to use this licensing model. Now they don’t have to. Simply create a repository of your own (github or anywhere else), upload your code and add the license of your choice. Then let us know and we’ll add your plugin to our lists in all the appropriate places.

    We’re live!

    The first version of the site is already up and running at:

    It lists all of my most recent plugins and links back to the original community site for completeness. Go on. Check it out. If you’d like me to add your plugin, send me a link to your repo or blog-post and I’ll add you to the list. If you’d like to help improve the look and feel or content of the site, Fork it! and send me a pull request.

    So you want to write a CodeRush plugin

    You have a simple idea for a CodeRush plugin.

    1. An Action you’d like to trigger from your IDE.
    2. A Refactoring or a CodeProvider you’d like to add.
    3. A new Context which you could use to fine tune the availability of your templates.
    4. A StringProvider, a TextCommand or a Code Issue.

    But you can’t be bothered with all of that drag and drop visual designer business.

    Visual Designers are Slow

    From the moment you reach for the mouse you know you’ve already lost speed. Visual designers aren’t just slow though. They’re very awkward to use. Even if they responded at the speed of light, they’d still be awkward to use.

    Assuming that they invoke instantly, you still have to wave that mouse around all over the place in order to get anything done at all.

    For a simple control/component with 2 properties and 2 events the procedure is something like this.

    1. Mouse –> Open Toolbox
    2. Mouse –> Drag control onto design surface
    3. F4 –> Bring up properties tool window
    4. Mouse –> Scroll to find property
    5. Mouse –> Select property
    6. Keyboard –> Set property value
    7. Mouse –> Scroll to find property
    8. Mouse –> Select property
    9. Keyboard –> Set property value
    10. Mouse –> Click event tab in properties toolwindow.
    11. Mouse –> Scroll to find event
    12. Mouse –> Double-click Event to produce event handler.
    13. F4 to return to properties tool window
    14. Mouse –> Click event tab in properties toolwindow.
    15. Mouse –> Scroll to find event
    16. Mouse –> Double-click Event to produce event handler.
    17. That’s 8 mouse operations and 4 keyboard operations. It’s also 8 context changes (Mouse –> Keyboard or Keyboard –> Mouse)

      There have been improvements in this area (The toolbox can be searched or filtered using the keyboard), but so much switching from mouse –> keyboard –> mouse can’t be a good thing. Now I know what you’re thinking. There’s likely some set of really easy to remember set of keystrokes that can emulate all that mousing around. Yeah I’m sure I heard something like that once as well, but I sure can’t remember it now. It obviously wasn’t that intuitive.

      So what’s the alternative?

      Enter… CodeRush

      Well what is the toolbox ultimately used for? That’s right, it’s an easy way to write code quickly.

      Ok well CodeRush already has many ways to write code quickly. One of the most effective of these, is also one of the easiest to use.


      Type a few characters…. Hit space… Oh look there’s your code. Awesome!

      So back to the main point of this post: I’ve been putting together a group of templates that can ease the creation of plugins. I’m collecting these in a Github repository which I’m just going to leave over here.

      I’ll go through them in some upcoming posts, but the general gist is this.

      1. Place caret in plugin class.
      2. Invoke template.
      3. Call register method from InitializePlugin method.
      4. Follow instructions left in plugin.

      I’ve summarized these instructions in this handy screenshot.

      The Templates

      The templates presented emit code designed to replace the drag and drop designer approach typically used for such things. This is my own preferred approach. I do not suggest it is the only approach. However it is one that works for me :)

      Upcoming posts will walk you though several templates including (but not limited to) NewAction, NewRefactoring and NewCodeProvider.
      So stick around and we’ll help kick-start that plugin for you.

    Community Callout – FakeItEasy CodeRush Templates

    CodeRush User Richard O'Neil has created his own set of FakeItEasy templates to speed his development.

    These templates give him an edge when creating his fake objects using this popular framework.

    In case you’re unaware, FakeItEasy is a Mocking framework for .Net which is hosted on GitHub


    As I write this, Richard has support for the following templates:

    Setup FakeItEasy

    Trigger: ufie<space>
    Effect: Adds ‘FakeItEasy’ to the namespace references of the current file.


    Note:This template does not need to be called explicitly since it is called for each of the following templates already. Additionally, the reference is added in the correct location above the class definition.

    Create a Fake Object

    Trigger: fief<space>
    Expands to:


    Set up a call to return a value

    Trigger: fiecr<space>
    Expands to:

    Creating ignore parameters

    Template: fieany?Type?


    Expands to:

    Expands to:

    Being the awesome community person he is, Richard has published these templates on github so anyone can take advantage of them.

    If you’d like to use these templates in your own projects, download the xml file from the repository and follow the Import instructions in this post

    Update: If you’re using the Template Importer plugin, you can pass it this url to import the FakeItEasy templates straight off the web.

    Exporting and Importing CodeRush Templates

    CodeRush’s Templates are awesome.

    Sadly we can’t ship every conceivable variation of awesome out of the box. However we do ship the ability for you to write your own templates.

    I’ve blogged about creating templates before, but thought it might be worth reminding you how to Export your templates for sharing and how to Import templates written by others.

    Exporting Templates

    From the templates options screen (Ctrl+Shift+Alt+O, Editor\Templates) you should arrange your templates such that:TemplatesExportFolder

    1. Custom templates are positioned in a custom folder within the Hierarchy
      Note: This isn’t required as such, but it can make a great deal of sense to have all your custom templates beneath a single location.
    2. Position the templates you’d like to export in a folder on their own.
      We’re not trying to make the templates feel bad, it’s just that the unit of export for templates is folder based.
      For example: I have a bunch of plugin templates positioned in a Custom\Plugins folder.

    To perform the actual export…

    1. Right click the folder you’d like to export and choose Export Folder…
    2. Name your export file. (The default name provided is based on the language of the template set, and the folder being exported.)

    At this point you have a totally portable .xml file which can be taken to another computer and imported.

    TemplatesImportTemplatesImporting Templates

    From the templates options screen (Ctrl+Shift+Alt+O, Editor\Templates)

    1. Ensure you have the correct language selected.
    2. Right anywhere in the template tree
    3. Choose Import Templates…
    4. Locate and choose the file containing the templates you’d like to import

    If the template file indicates a folder that you already have then you will be offered the following dialog:


    The default choice here will wipe any duplicate templates found in your existing system in favour of those found in the templates file.

    In the example above, I am importing some templates into a ‘Custom’ folder so those are the only ones at risk.

    If you are unsure, feel free to pick the 2nd option and change the top level folder to something new (perhaps ‘Custom2’). You can then examine the plugins imported into that folder and decide which ones you’d like to keep. You can either move them around manually or decide that they’re all fine and reimport over the top of the original location (remembering to delete the ‘Custom2’ folder if this is the case)


    So you now have the tools to let you export some of your own awesome templates for others to use.

    Why not spread the wealth and share your templates with co-workers or even with the wider community.

    In some upcoming posts I’ll be doing exactly that. Sharing some of my own custom templates with you to help make your coding lives easier.

    Update: Another way to import CodeRush templates, is to pull them straight off the web using the Template Importer

    More Posts