Rory Becker - DevExpress CodeRush Blog
  • More CodeRush Plugins added to the Visual Studio Gallery

    For those of you who didn’t already know, several of our CodeRush plugins are already available from the Visual Studio Gallery.

    Plugins added to the Visual Studio Gallery can be installed from within Studio via the Tools\Extensions and Updates menu.

    Additionally Studio will let you know if a new version is released. Assuming you agree, it will download the new version and install it for you as well.

    So we’ve just added another 5 plugins to those already up there making it even easier to pimp your IDE.

    For reference these are the plugins we’ve just added:

    To browse a full list of CodeRush plugins on Visual Studio Gallery just visit Tools\Extensions and Updates in Studio and search the online section for CodeRush

    Alternatively, just follow this link.

  • New CodeRush Plugin Template - NewMetric

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

    What is a Metric

    A metric is a measurement of some quality of your code. In this case it is a per-method measurement. CodeRush displays the metric for each member, on left of the member in question.

    CodeRush ships with 3 such metrics:

    • Lines of Code
      Exactly what it sounds like. This metric measures the number of lines occupied by the method. This is a pretty basic metric which includes the signature and braces of the method.
    • Cyclomatic Complexity
      A measurement of the number of paths through your code. The higher this value, the more tests will be needed to cover the method’s behaviours correctly.
    • Maintenance Complexity
      This metric weights each element of the method according to how it affects the maintainability of said method. You can read more about this metric here

    You can choose which metric CodeRush displays, by clicking the current value and choosing another metric from the list. CodeRushMetricChoice

    The NewMetric Template

    As you’ll have guessed based on previous posts in this series, the purpose of the NewMetric template is the quickest way to create your own metric?


    As with other plugin templates, this one is intended to be expanded (NewMetric<space>) in the body of your plugin class.

    It will produce code that looks like this:


    As with other plugin templates, you’ll have to give your Metric 3 names.

    As a quick reminder, these are:

    • 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 Metric.
    • Internal name
      This value is used internally by CodeRush. It should be unique, since it will be used to add your Metric to an internal dictionary. Later you can use this name to get a reference your Metric from another plugin.
    • Display Name
      This value is used for the text displayed when your provider is added to the drop down list of metrics provided inline.

    Next up, you’ll have to call the registerXXXX method (just generated and named) from within your plugin’s InitializePlugin method.

    Finally you need to implement your plugin’s new metric. This is achieved by adding code to the GetMetricValue handler (also stubbed out by the template).

    Typically you’ll examine the source of your project and perform some sort of calculation based on the LanguageElement passed to you in e.LanguageElement. Then you’ll assign the result of this calculation to e.Value.

    So if you were looking to replicate the lines of code metric, you might use code similar to:


    ..and that’s it.

    In Summary…

    • Expand NewMetric template
    • Call RegisterXXXX from InitializePlugin
    • Implement your metric (possibly in a single line of code).

    …and you’re done.

    Where do I get this template?

    As usual this template is available from the CodeRush Plugin Templates repository on GitHub

    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 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

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, Delphi, HTML5 or iOS & Android development. 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-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners