Rory Becker - DevExpress CodeRush Blog
  • New CodeRush Plugin Templates – NewCodeProvider and NewRefactoring

    Note: The templates referred to by this post do not ship with CodeRush. To install them, see instructions towards the end of the post.

    This post describes two more templates in my Plugin Templates series. The series itself is introduced in my previous post - So you want to write a CodeRush plugin


    The NewRefactoring and NewCodeProvider templates are the single quickest way to get started creating Refactoring and CodeProvider(Collectively called ContentProviders) plugins

    These types of plugins add items to the Red (Refactoring) and Blue(Code) sections of the CodeRush SmartTag menu.


    The templates work very similarly to My previous NewAction template in terms of placement. ie You should expand them in the body of your plugin class and then call the generated register methods from within your plugin’s the InitializePlugin method

    This is how the NewRefactoring template expands:


    …And here is what you get when you expand the NewCodeProvider template


    Note: As before, you’ll need to call the appropriate registration method from your InitializePlugin method

    You can see they are structurally very similar. they both create Register, CheckAvailability and Apply methods. In each case there is a small amount of customization to be done in order to get your ContentProviders up and running.

    You’ll have to give your ContentProvider 3 names.

    • Your own reference.
      The first name is your own reference. The phrase you type here is used to name the objects and associated methods of your ContentProvider.
    • Internal name
      This value is used internally by CodeRush. It should be unique, since it will be used to add  your ContentProviders to an internal dictionary. Later you can use this name to get a reference your ContentProvider from another plugin.
    • Display Name
      This value is used for the text displayed when your provider is added to the CodeRush SmartTag menus

    Next you’ll have to provide the code for:

    • Your CheckAvailability method
    • Your Execute method.


    Availability is about determining if it is currently appropriate for your ContentProvider to be present on the CodeRush SmartTag menu.

    Your CheckAvailability method is where you do this. In the unlikely event that your Refactoring\CodeProvider is always supposed to be available, simply leave the code as it is.


    In most cases, your ContentProvider will only make sense under certain circumstances. If these circumstances are not met, then it makes more sense to simple not show your ContentProvider in the SmartTag menu.

    Consider the “Split String” refactoring. This refactoring is designed to allow you to change




    It’s clear, there is no point in providing this Refactoring, unless the user’s caret is within a string.

    Thus the SplitString_CheckAvailability method might look something like this:


    See how it only sets ea.Available to true if the ActiveString is not null. ie The caret is on a string literal.

    Of course you should feel free to make your determination in any way you see fit.

    You could:

    • Analyse the code where the caret is.
    • Analyse the project or the files within it.
    • You could base your own availability on the availability of another CodeProvider.
    • Look for code smells or other patterns.

    If you really want to, you could call out to the web, and check a webcam to see if there’s a blue moon Smile

    Just keep in mind that the check you perform here, will be performed quite often as the user moves around the code. This code needs to be as fast as possible.


    As you might imagine, the ContentProvider_Execute method is where you perform the main function of your ContentProvider.

    You might:

    The sky really is the limit.

    Ok Cool, so how do I get these templates?

    The NewRefactoring and NewCodeProvider templates are available in the CodeRush Plugin Templates repository on GitHub

    You can import them the traditional way

    OR you can use the Template Importer and point it at

    • This URL for the NewRefactoring template
    • This URL for the NewCodeProvider template

    If you have any suggestions to improve any of the templates in this series, feel free to contact me via email or on twitter.

    If you so inclined you could even fork the project, make some changes and send me a pull request.

  • New CodeRush Plugin - Template Importer

    I was rereading my previous post New CodeRush Plugin Template – NewAction

    In it I asked you to ….

    • Visit a page on github.
    • Locate an XML file.
    • Download that file.
    • …and finally Import the file.

    However it occurs to me that this is rather lengthy and awkward.

    What if we could automate that a little more?
    What if we could write a plugin which was able to download templates and install them itself?
    What if….

    Aw nuts! Never mind ‘What if’……….Let’s just do it!


    This is Template Importer.

    Note: It’s pretty clear that I’m no UI expert, but that’s another good reason to open source and accept pull requests.

    In brief:

    It can do 2 amazing things.

    • It can import exactly 1 exported set of templates by providing the address of an exported template file to the 1st box and pressing Import.
    • It can import multiple sets of exported templates by providing the address of a package to the 2nd box and pressing Import.

    More Detail

    Import Templates (from the Web)

    A exported set of templates (see Exporting and Importing CodeRush Templates) is just an XML file. They’re easy to create, easy to store and easy to publish for others to use. All that’s really needed is an easy way to strip them off the web, and import them into your system.

    The top half of the screen does exactly this. You can specify the url of a raw template file, and then click the Import button.
    (For your convenience, the little “>” button on the left will copy the example into the live box)

    The example file is published on github, but there’s no limit to where you can put these files.

    • Host them on your intranet.
    • Put them in your dropbox account.
    • Attach them to your blog.
    • ftp them into place.
    • ‘git push’ them into place.

    Anywhere they can be reached by http is good enough.

    I’m planning on uploading a lot more of my templates to various appropriate github locations.

    But wait …. It gets better!

    Import Packages (from the Web)

    Q: Hang on… What is a package?

    A: A package is a simple xml file (Yes I like XML files. Sorry.) which contains the urls of one or more exported template files.

    For example here is the contents of the example package that is listed within the TemplateImporter by default.


    The xml is fairly simple.

    The template node has a url attribute (pointing the way to a template file) and a language attribute (specifying the language of the templates within the file).

    Of course you can add as many ‘template’ nodes as you want, which means that you can create single package file that lists all your favourite 3rd party templates and then import them onto any machine you like in one hit. Great for being able to pull your standard templates onto your co-worker’s machine.


    The Current Template Importer is limited in a few ways.

    • Template Import only understands VB.Net and CSharp templates.
      There is no information held in a set of exported templates regarding the source language from which it came. The importer makes an intelligent guess based on the prefix of the filename you point it at. It understands Basic, VB, CSharp and CS.
      Note: Package Import does understand the other languages. As indicated, the package will contain a language attribute for each url resource listed. this is used by the importer in order to place the templates in the correct location.
    • There is no preview.
      There is no option to preview what you’re getting in advance of getting it. Unless of course you’re prepared to wade (and I mean wade) into the xml of the files you’re instructing the Importer to import.
    • There is no selective import.
      You get every template in the file(s) or nothing at all.
    • The import is additive only.
      It will add these templates at their own specified locations in addition to anything else that might be there already. This includes copies of the exact same templates that you imported 5 seconds previously. In order to get only the latest version of a set of templates previously imported, I recommend deleting any previous revisions of those templates prior to each import.


    There are no real safeguards in place yet. Be careful.

    • Don’t import templates from a source unless you explicitly trust that source.
      Really this one should speak for itself.
    • Don’t export templates from outside your custom folder.
      If someone were to import those they’d wind up with duplicate core templates. I’m honestly not sure what the effect would be, but it would certainly cause a mess
      If templates are always exported from within custom, they they’ll import there as well. This then limits the potential mess to the users custom folder.
    • Only import templates into your Custom folder.
      If you only ever import templates into you custom folder, then you can always restore your system to normal simply by hosing that folder.

    So where can I get it?

    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.


    You can either:

    • Bind a key to the ‘ImportTemplates’ command, and trigger it with the keystroke of your choice.


    • Use the ‘Import Templates’ menu item I’ve placed on the CodeRush menu.

    In future when I provide one or more templates, you should be able to use this plugin to point directly at the file’s url and suck the templates straight off the web without all that tedious mucking about with Right click … Save As etc

  • New CodeRush Plugin Template – NewAction

    Note: The template referred to by this post does not ship with CodeRush. To install it, see instructions towards the end of the post

    This post describes the first new plugin template in a series. The series itself is introduced in my previous post - So you want to write a CodeRush plugin


    The NewAction template provides the single quickest way to create a new action for your plugin. Actions are named bits of code which an user can trigger via a shortcut (mouse, keyboard or menu).

    Each new action creates an entry which will be placed in the commands dropdown on the shortcuts page.


    First you’ll need a plugin project. An existing project is fine, or you can create a new one via:

      1. File \ New \ Project
      2. DxCore \ (VSIX) Standard Plug-in


    Once you are in your new project, you’ll see code like this:


    As indicated in the screenshot, there you should:

    • Expand the template in the body of your main plugin class.
    • Call the new registerXXXX method from within the InitializePlugin method.

    In more detail the steps are:

    1. Expand the template
      1. Position the caret in the body of the plugin class
      2. Type NewAction and hit <space>
        (Note:Those using FrictionFree mode will need to use <tab> instead of <space>)

    2. Fill out the generated fields: The first is used to name the methods associated with your action. the second is used to provide the internal name of your action. The one which CodeRush will use and which must be bound to a shortcut in order to be triggered.
    3. Add a call to the generated Register method to your plugin’s InitializePlugin method.

    4. Add your plugin specific code to the generated Execute method. In the example below I have added a simple call to show a simple "”Hello World” MessageBox.


    All of these steps involve coding. None of them take you through designers, and there’s no searching for the right properties or events.

    The Action does, of course, have more properties and events to investigate, but this template provides the basic setup which almost every action will require.

    Download and Install

    This template is available in the CodeRush Plugin Templates repository on Github

    To install this template you need (the raw version of) CS_NewAction.xml from the repository.

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

  • 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

  • TemplateExpand with CollapsedRegions – How does it work?

    Disclaimer (Yes again)

    Yup, some people still don’t like regions. If that’s you, then you might not be that interested in how a region-appreciative plugin works.
    We’re not here to discuss if they’re good or bad. We’re here to show you how the plugin from my previous post does what it does.


    There are only 2 parts to this plugin.

    1. Expand the Template
    2. Collapse Regions

    Expand the Template

    If you’re looking to write an action which needs to be able to expand templates as part of it’s remit, then there really is no better way to get this done, than to call the original command which already takes care of this.

    To call another command, you’ll want code like this:


    Locate Regions to Collapse

    So the next issue is which regions to collapse. You see there might already be regions in the document before your template is expanded, and you don’t necessarily want to collapse those.

    Ideally we would like to know the sourceRange into which the template expanded. The TemplateExpand command does not provide this information out of the box, so we’ll have to work it out ourselves. I picked what seemed at the time, like the simplest approach possible.

    I calculate the LinesFromStart and LinesFromEnd. (ie the number of lines from these points to the line the caret is on.)


    …then these values can be used (together with the size of the post-expansion document) to calculate the size and position of the region into which the template expanded.


    Collapse the Regions

    Once we have expanded our template, and have a range of code to process, it should be a simple enough procedure to iterate through RegionDirectives in this range and collapse each of them in turn.


    Except that it’s unfortunately not that simple.

    A Problem of Timing

    As indicated, the problem is one of timing.

    You see VS is a multi-threaded application. This allows it to delegate certain non-essential tasks to background threads. These task are assumed to be less vital than some others and thus will take something of a back seat if other more processor intensive work is being done.

    So what does this mean for us? Well it turns out that fully hydrating new regions added to code is considered a less important task.

    You can definitely understand that point of view. The 500ms delay between adding a region and it being considered a real region is nothing right. I bet most of you have never even noticed that small delay between moving off the line after creating a region and the point when VS recognises it as a region and adds outlining to it.

    However as indicated this does provide us with a small issue.

    If we run our code as suggested so far, we’ll hit a situation where the instruction to collapse a detected region is ignored, because there isn’t yet any sort of outlining associated with the region(s) in question.

    So what to do instead?

    Well the simplest solution is just to wait until the relevant information is available. I’d prefer to do this via event, but at the time of writing the code, I couldn’t find one that would alert me at the proper time.

    So I created a DelayedRunner class (main code below) whose purpose is to repeatedly run a passed func<bool> until such time as that function returns true.

    I added a parameter to specify a delay between each execution, and another to provide a maximum length of time, after which the DelayedRunner would turn itself off and essentially give up.


    This required that I alter the code of CollapseRegions so that it returned a bool indicating it’s level of success.

    Note: If no regions are detected in the range, the routine returns success immediately.


    Finally this delayed execution is executed using the following code:



    The multithreaded nature of this command means that it is not possible to wrap this up in a singe UnitOfWork and add it to the undo stack. Therefore when attempting to undo the effects of this command, the user will have to invoke Ctrl+Z twice to achieve the desired results.

    As always the code for this plugin is available on github and the latest release is also available as a VSIX

  • New CodeRush Plugin – TemplateExpandWithCollapsedRegions


    Yes I know. Regions are bad. Regions are awful. Regions should be shot repeatedly until dead. Try to bear in mind that not everyone views everything the same way, and openness to alternatives is a good thing. For the purposes of this blog post, I’m going to ignore the fact that some people see regions as a bad thing. The customer asked for this functionality. Hopefully it will be useful. For the benefit of the customer in question, I’m going to try to keep them relatively anonymous :)

    No regions were harmed in the making of this plugin. Sorry.

    Customer Request (Paraphrased for security reasons)

    I love CodeRush Templates. Is there a way to have CodeRush expand a template, but leave regions that it generates collapsed?

    Short answer: No, there’s nothing built in. Sorry.

    Longer Answer: That sounds like a challenge. Let me see what I can do.

    TemplateExpand with Collapsed Regions

    When you expand a template in CodeRush, your space (or sometimes Tab) key is firing our TemplateExpand command. This in turn invokes all sorts of clever magic and emits text and other things into your editor, with considerably less effort on your part, than if you’d had to type it all yourself.

    This new plugin provides a single new (alternative) command TemplateExpandWithCollapsedRegions.

    To use it, simply bind it to a shortcut of your choice. In testing I have bound it, as I usually do, to Ctrl+T. You can of course pick anything you like. You may even decide you like it so much that you want to replace the original TemplateExpand command. If that’s the case then you’ll need to locate the existing binding on the shortcuts page, and alter the command from TemplateExpand to TemplateExpandWithCollapsedRegions.

    Once you have assigned this command to a shortcut you can use it just like the original command.

    This latest version of this plugin can be found on github.
    Feel free to download, install it and see what you think Smile

1 2 3
5 6 7 8 9 10

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners