CodeRush Plugins - What are they good for?… Absolutely everything!

Ok so I might be overblowing things slightly, but stop and think for a moment…

Mark Miller built a plugin that allowed him to interface a wireless guitar controller, with Visual studio. Using this plugin, CodeRush and his guitar instead of a keyboard, he was able to code faster than most people could with a keyboard and vanilla VS.

Come on… That is Awesome!

Oh yeah .. And don’t get me started about his next scheme.

Anyway… all that out of the way… What *is* a plugin good for?

Well that’s an interesting question. Well let’s put it this way….

CodeRush == DXCore + Plugins

Ok sure but what does that mean?

It means that CodeRush is technically nothing more than a bunch of plugins built on top of the services of the DXCore. This in turn means that the DXCore provides everything you need to start building plugins as powerful as the features in CodeRush.

So why is writing a plugin using the DXCore easier than writing it without.

Ok, let’s have a look at the benefits of the DXCore:

Managed Code
The DXCore removes the need for programming against COM Interfaces for the vast majority of plugin code, without removing your access to that facility in case you should need it. Ask anyone (Oh ok … any semi-respectable programmer) … “All other things being equal, would you prefer to write against COM or against a managed library?”. If you find someone who votes for COM, you have found a <Insert polite term here>*.

*Note: I did asked my followers on twitter, what a polite term for such a person would be. Answers included ‘a lunatic’, ‘grandpa’, ‘old’, ‘sadist’ and my personal favourite ‘There is no appropriate polite term for such a guy’.

Get straight to the point.

When you code add-ins with the DXCore, it can be a simple matter of dropping a component on a design surface setting a couple of properties (typically for sensible naming and such), and then handling one or more events. You don’t have to mess around with registering your plugin with anything. There’s no shimming to create tool-windows, and you don’t have to perform multiple casts on everything, just to get access to properties that you should have been able to see all along. The DXCore lets you just get on with creating your plugin. It worries about the glue so you don’t have to.

Support all the way back to VS2005

Just like it says on the tin. The DXCore can provide you with all sorts of contextual information and understands many different versions of each of the languages that are supported. This means that you can easily write a single version of a plugin, and have it support the last 3 versions of studio (VS2010, VS2008 and VS2005) without needing to recode or recompile. Your plugin can be installed in a single location on a machine which has all 3 of these IDE’s installed, and it will function quite happily in all of them. This does not mean that it has to function exactly the same in all 3. If you like you can ask the DXCore which version you’re operating under, and you can alter your plugin’s behaviour accordingly. So it’s not something you need to worry about, but if you want this sort of info, it’s available on tap for you to do with what you will.

Deep Language Parsing

The DXCore parses everything. I’m serious I really mean every part of your source. I remember trying to write CodeGen code before finding out about the DXCore. It was a black art at best, and worse there wasn’t much support for anything more detailed than a method declaration. The DXCore parses everything into an abstract syntax tree (AST) of objects which is completely language independent. Everything from the source files, through namespaces and types (Classes Structs and Interfaces) then on into fields, methods, properties, accessors … statements, branches, loops … expressions, primitives. Like I said… everything.

Cross Language Plugins

Given my previous point about how well parsed your code is, and that the result is an AST which is decoupled from your code, it should come as no surprise really, that this means a DXCore Plugin is able to perform it’s task needing little-to-no knowledge of the language within which it is operating. That’s right. you can write a single plugin which can work just as well with C#, VB.Net or even JavaScript. All these languages are parsed into the same objects within the AST, and can be analysed to produce information based upon this abstract nature. For example the ‘maintenance complexity’ metric feature of CodeRush works with all 3 languages, because what it’s analysing is loops, conditionals, declarations and the like. The feature itself has no real knowledge of any of these languages, because it doesn’t need to. The DXCore has been parsed out all of the language specifics and their nuances into an AST. All that’s left to do is analyse the AST and produce a result, which is exactly what the ‘Maintenance Complexity’ metric does.

Likewise if you construct an AST of your own, adding classes, members, statements etc, it can be then emitted into any of these languages with a single function call. Allowing you to create Refactorings and CodeProviders that work across multiple languages without additional coding or even fully understanding the syntax of those languages.

Rapid Plugin Prototyping

Coding against the DXCore is quick. I’ve lost track of the number of times that I’ve said to myself "I wish that studio could do X” or “The lack of Y really annoys me” or “Wouldn’t it be great if…”

Starting from a raw “Standard Plugin” project you literally drop a component on the design surface (if that’s the way you prefer), fill out a couple of properties and then handle one or more events to provide the specific functionality you’re after.

You can have a workable prototype plugin in seconds, and a fully working version in minutes. If you add to this, the ability to change the code of your plugin on the fly whilst it’s still running inside Visual Studio (Edit and Continue**) and you’ve got a very flexible way to build plugins to do all sorts of crazy things.
I’ll be showing you in subsequent posts, how individual types of plugins are created, and I’ll provide you example code for achieving all sorts of cool stuff.
(**‘Edit and Continue’ really is teh awesome. Except if you’re coding in C# and like to use Lambdas, but hey nobody is perfect.)

Summary

What it boils down to is this: Visual Studio is not perfect. The guys on the IDE team at MS are great. No really they are… Look at what they have achieved. It really is awesome… but they simply cannot ship features as fast as we come up with requirements. The DXCore gives you the ability to take matters into your own hands.

Imagine for a moment, all of your accumulated skill from all those years of programming that you’ve done. Wouldn’t it be nice if you could use some of that, to enhance your own day to day life, rather than always directly in service of your customers. I’m not suggesting the you should ignore your customers, but if your own programming life can be made smoother, then the benefits of this are passed on to your customers anyway through your increased productivity.

The DXCore gives you back the power to do just this. So stick with me here, as I guide you through the process of building some plugins of your very own.

Free DevExpress Products - Get Your Copy Today