Mark Miller

Interesting CodeRush Blog Series

Mark Miller (DevExpress) — Wed, 14 Jul 2010 21:13:00 GMT

CodeRush user Jason Follas has started an interesting blog series on CodeRush; interesting because Jason talks about essential and important CodeRush features from his perspective. So far in the series Jason discusses:

Great work, Jason! Looking forward to see what else you have in store for us.

Working with Color in CodeRush

Mark Miller (DevExpress) — Mon, 26 Apr 2010 18:37:42 GMT

Working with color in source code has never been as easy or intuitive as it should be. Looking at hex values or a color name like Bisque and then trying to imagine what that color looks like is a challenge. Finding the correct color to use in a new style in a CSS file is also challenging.

Furthermore, going from color to code is rarely a picnic.

Fortunately, CodeRush 10.1 brings developers much closer to the real colors with new Color features. In this post I’ll discuss CodeRush features for working with color, both new and old.

Generating Color Declarations from HTML

This Intelligent Paste feature has been around for years. Simply copy an HTML color declaration (e.g., “#4B70BC”) and paste that inside a C# or VB file inside a method, property accessor, or inside a type (but not in a member) on an empty line, and you’ll get something like this (C# example shown):

This intelligent paste will create a local variable or a field, depending upon where you paste. As with all Intelligent Paste operations, you can press Undo to get the literal contents of the clipboard if you don’t like the CodeRush version. All Intelligent Paste operations are defined on the Intelligent Paste options page. Follow these steps to get there if you want to see them all:

From the DevExpress menu, select "Options...".
In the tree view on the left, navigate to this folder: Editor\Clipboard
Select the "Intelligent Paste" options page.

Note: This page level is Advanced, and will only be visible if the Level combo on the lower-left of the Options dialog is set to Advanced or Expert.

Working with Color Declarations from Templates

When working with color from templates, the mnemonic to remember is “CL”.

Normally (without CodeRush), if I want to bring up a list of named colors using Intellisense, I have to type in “Color.”. With CodeRush installed, I can now simply type “CL” (lower case is fine) followed by the space bar to expand the template, and this is important: the caret must be at a location where a Color expression is valid (so not on an empty line but instead as a parameter to a method or an assignment to a variable or a property. Also, the active project must have a reference to System.Drawing or System.Windows.Media (CodeRush will add the appropriate namespace reference to the source file if needed).

If you need a color from the SystemColors class, expand the “SYC” template (again, lowercase is fine, but for clarity I like to specify templates using uppercase letters).

Back to that CL mnemonic. You can combine this shortcut with other CodeRush code templates that work with types. For example, MCL will generate a method that returns a Color, VCL will create a variable declaration (local, parameter, or field) of type Color, and ACL will generate an auto-implemented property of type Color. There are also PCL (for properties of type Color with backing store) and NCL for newly-initialized variables of type Color. And there is “CL.E” for Color.Empty.

Try these in a project that references System.Drawing or System.Windows.Media.

Color Swatches in the Code

Remember that color declaration we generated at the top of this post when I pasted a color reference into the code? You probably noticed that bluish rectangle under the word Color. Here’s that screen shot again:

And here’s a variation with different values:

Those rectangles appearing below the Color type reference are color swatches. These are very cool. Now you no longer have to reverse engineer RGB color values in your head to figure out exactly what color you’re looking at in the code.

The CodeRush Color Dialog

So what happens when you want to edit a color in the code? Good news: just click the color swatch with the mouse and up pops the CodeRush Color dialog, which looks like this:

The CodeRush Color dialog consists of several pages, which we’ll examine in a moment. At the bottom of the CodeRush Color dialog is a sample color swatch which reveals the selected color, and to the right of the sample is a Favorites button.

We’ll talk more about the cool things you can do with favorite colors in a moment. But first, let’s take a look at the pages.

The Color Picker

The “Picker” page, the one you see in the screen shot above, is perhaps the most weighty. If you need to pick a color based on hue, saturation, brightness, red, green, or blue, you can do it here. You can also set opacity, enter an HTML color (including shorthand for web-safe colors such as “369”), and change a selected color to it’s nearest web-safe neighbor. And you can select a color from an existing image or window appearing on your desktop by clicking the eye-dropper tool.

When working with color, you can use one of two mechanisms: red, green, & blue or hue, saturation & brightness (RGB and HSB). You may prefer to work with HSB on the Picker page since these attributes make it easy to change the brightness or the saturation without modifying the hue, which can produce nice color variations like this:

or this:

Keeping most of the UI colors in the same hue is useful for reducing visual noise in a user interface.

Regardless of which of the two mechanisms you choose to work in, specifying a color on this page is always a convergence of three values. I like to visualize this as a cube which holds all colors. If I’m working in RGB, the dimensions of that cube are 256x256x256.

Here’s an example of a three-dimensional arrangement of colors organized by saturation (width), brightness (height), and hue (depth):

So to specify a color in this three-dimensional space the Picker page gives you a two-dimensional grid, like this:

and a one-dimensional vertical gradient, like this:

These two controls work together to let you specify any color in this three-dimensional space. The vertical gradient allows you to select any plane in this space, and two-dimensional grid lets you select a color on that plane.

The vertical gradient is useful when you want to isolate one of the three attributes of the cube you’re working with onto a single dimension, allowing adjustments to only one value while keeping the other two attributes static.

To isolate an attribute just click its corresponding radio button on this page.

For example, to isolate the Saturation attribute, click the “Sat:” radio button.

Notice the labels on the two-dimensional grid have changed to show Brightness on the vertical axis and Hue on the horizontal axis.

Isolating the Brightness attribute looks like this:

Things get interesting when you isolate one of the RGB channels. For example, here’s Red:

Here you can see where the color will go as you increase or decrease the RGB values.

Here’s what it looks like when you isolate the Green channel:

And for completeness, here’s what it looks like when you isolate the Blue channel:

If you need a color from the desktop, click the Eyedropper button and then click on the color you want. A sample of the color under the eyedropper will appear below the button, and to the right you’ll see a magnified portion of the screen with a rectangle in the center representing the eyedropper position.

If we’re working with a color that isn’t web safe, the “Make Web Safe” button will be enabled. Clicking it will to take the selected color to its nearest web-safe neighbor, like this:

Right above the Make Web Safe button is the hex edit control, useful for copying or pasting hex triplet representations of color (for example, “B6005A”). You can also use a three-digit shorthand when representing web safe colors, for example enter “369” in the hex edit control and you’ll get this:

Which is shorthand for #336699.

Web Colors

Speaking of web-safe colors, let’s switch to the Web page, where you can select from all 216 web-safe colors:

Named Colors

Here’s the Named page for .NET colors based on the X11 color names:

System Colors

Document Colors

The Document page shows all the colors defined in the active document (before taking this screen shot I opened a C# class which defined many colors):

Favorite Colors

And finally, we have the Favorites page, which might initially look like this:

The favorites page holds favorite colors in groups called palettes.

There are three interesting buttons on the top row of this page:

	Delete Selected Color
	Delete Active Palette
	Create New Palette

You can rename the active palette simply by typing in a new name in the combo box at the top of the dialog (press Enter to commit the change or Escape to cancel). For example, let’s rename this palette to “My Faves”, like this:

Press Enter to commit the change, or you can commit the rename by simply moving focus away to another control.

At the bottom of the CodeRush Color dialog, to the right of the color sample, sits the Favorites button.

If you click the button, the sample color will be added to the active palette page.

Let’s add another color to this page. Click on the Named color tab, select DarkOrange:

Then click the Favorite button, and watch what happens under the mouse:

The Favorites button changes to a Return button, so a single click on this can get you right back to the page you started from. This makes it easy to add several favorite colors from anywhere in the CodeRush Color window.

There’s one more cool thing you can do with favorite colors. To demonstrate, let’s create a new palette page. Click the Create New Palette button.

Now let’s go to the Picker page and find a favorite color, like this:

For this demo I’m grabbing the DevExpress blue from the web site using the Eyedropper.

Now, right-click the Favorite button and select Add Color Distribution, then click the number of colors of varying lightness you want to add in the same hue as this color. I’ll select 21.

Which generates 21 colors based on the selected color, like this:

Generating the Color Reference

Once you have the color you want, just click the OK button and the active color reference will be replaced with a reference to the color selected. Here’s the DevExpress blue placed in a C# file after clicking OK:

Oh, and if you’re still wondering what Bisque looks like, here it is:

We hope you enjoy the CodeRush features that make working with color easier. As always, let us know what we can do to improve your development experience.

CodeRush Xpress & CodeRush Ready for Visual Studio 2010

Mark Miller (DevExpress) — Tue, 13 Apr 2010 18:29:00 GMT

Both CodeRush Xpress and CodeRush have been released this week. CodeRush Xpress went final and became available only a few seconds after Visual Studio 2010 became officially released.

The full version of CodeRush 10.1 is available on the Betas tab of your client center download page.

While CodeRush Xpress is final, the full version of CodeRush 10.1 is expected to be final by the end of April when the rest of DXperience 10.1 ships.

Spend a Day with Miller in Vegas! (Free CodeRush Training)

Mark Miller (DevExpress) — Wed, 10 Mar 2010 22:43:11 GMT

Hey kids,

Ever wish you could spend the day with your good old buddy Mark Miller in a Las Vegas training room?

Just sitting back, shooting the breeze and talking about whatever CodeRush thing is on your mind? Well the good folks at DevExpress are working hard to make your dream come true. :-)

That’s right, kids. DevExpress is putting together a full day’s worth of formal CodeRush training, tentatively scheduled for Thursday the 15th of April, the day after the DevConnections conference and the official launch of Visual Studio 2010 in Las Vegas. And like the title of this blog post reads, this training session will be 100% free.

Not only will it be free, but DevExpress will also be giving away prizes, we’ll hear from a special guest speaker from the Visual Studio team at Microsoft, and there’ll be some yummy food to eat. All courtesy of DevExpress. It’s crazy I tell you. Absolutely crazy. :-)

As for content, we’ll start off the morning talking about CodeRush Xpress, then we’ll move into the more powerful features of the full version of CodeRush, wrapping up with extensibility, showing how to radically customize your IDE. The course content will look something like this:

CodeRush Xpress
- Navigation
- Selection
- Clipboard Features
- Declaration from Usage
- Refactoring
- Performance/Memory Comparison
CodeRush

Selection Embedding
Other Productivity Features
- Intellassist
- Auto Declare
- Smart Semi-Colon
- Smart Parens
Templates
Code Issues
Test Runner
More Code Providers
More Clipboard Features
More Refactorings
Other Language Features

ASP.NET
XAML
JavaScript
etc.

Extensibility
- Third Party Plug-ins
- Introduction – Creating a Simple Plug-in
- Creating Refactorings
- Creating Code Providers
- Creating Code Issues

So what’s the catch, you ask? It’s simple. We need to get a sense of how many people will show up, and we need to know very soon so we can book a room big enough to hold everyone. If this event sounds like your kind of fun and you can make it to Vegas in April, post a comment below to let us know of your intentions to be there. I expect that soon we’ll create a registration page so you can lock in your spot, and when that’s page is available we’ll let you know through blogs, tweeting, shouting and otherwise general mayhem.

Slicing and Dicing Strings with CodeRush for Visual Studio

Mark Miller (DevExpress) — Tue, 09 Mar 2010 21:51:00 GMT

CodeRush brings powerful string manipulation features to Visual Studio. Here are a few of my favorites:

Splitting Strings

When you need to break a string literal into two or three pieces. For example, let’s start with the following text:

public string GetGreetingText(int daysLeft)
{
return "Welcome back, customer. \nSo glad to see you. Days remaining on our special offer: " + daysLeft.ToString();
}

I can place the caret (the flashing I-beam that marks the editor’s insertion point) right before “Days remaining” text and press the CodeRush/Refactor! key (Ctrl+` by default) and then choose Split String.

This will split the string into two pieces.

Next, let’s select the last two expressions on this line:

Press the CodeRush/Refactor! key, and choose Extract Method to create a new method called GetDaysRemaining, like this:

Use String.Format

Next, move the caret down inside the string inside the GetDaysRemaining method. Press the CodeRush/Refactor! key and select Use String.Format.

This neatly combines the concatenation into a single string that is easy to read and so much easier to translate (translating string fragments is much harder to do when grammatical rearrangements are needed as part of the localization).

Speaking of translation…

Extract String to Resource

Move the caret inside the “Days remaining…” string. Press the CodeRush/Refactor! key and select Extract String to Resource, then select “Create new resource file”.

CodeRush will create a new resource file to hold this string, and highlight the resource identifier for an easy rename (tip: I like to use Camel Case Nav and Camel Case Select – Alt plus Left or Right arrow keys with Shift to select -- to quickly trim a long identifier down to a reasonable size). Let’s call this resource “DaysRemaining”.

Placing strings in resource files is a good first step to preparing your code for translation.

Splitting Strings, Revisited

The CodeRush Split String refactoring has a bonus feature built in: the ability to split a string into three pieces. Just select the portion of the string that you want to pull out and apply the refactoring. For example, in the code above, there is a “\n” appearing inside the string. This “\n” may be confusing to translators, it makes the string harder to read, and it may not be the most appropriate way to terminate lines on some platforms, so let’s take it out and replace it with the Environment.NewLine expression.

First, select the “\n”:

Press the CodeRush/Refactor! key and select Split String…

Applying the refactoring will leave you with this:

Notice the “\n” string fragment is selected for easy editing. Now we can use CodeRush’s “enl” template to replace the “\n” with a proper Environment.NewLine expression.

Introduce Format Item

See that “Welcome back, customer.” string in the code above? It would be great if we could actually pass in the customer’s name in place of the text “customer”. That would make the greeting certainly more personal. It’s easy to do this with CodeRush. Just select the part of the string that you want to replace, and press the CodeRush/Refactor! key, like this:

Apply the Introduce Format Item refactoring to get this:

Notice that once again the extracted string is selected for easy editing. Now let’s promote this string to a parameter. Press the CodeRush/Refactor! key and select Promote to Parameter.

And give the new parameter a meaningful name, like customerName:

Converting Text to Strings

Sometimes you need to work with a text coming from another environment, and that text span several lines or contain quote characters (that would need to be escaped). So in this example I used the “ms” template to create a method that returns a string, and I expanded the “r” template to get the return keyword and then I pasted in some XAML code that creates a TextBlock:

private string GetTextBlock()
{
return <TextBlock
Canvas.Left="25" Canvas.Top="5"
Foreground="Teal" FontFamily="Verdana" FontSize="18" FontWeight="Bold"
Text="Sample Output" />;
}

Of course this code will not compile. Fortunately we have CodeRush installed so getting it into its desired shape is easy. Just select the text we want to convert, press the CodeRush/Refactor! key and select Embed Selection | To string, like this:

CodeRush will convert the text into a string, like this:

Nice. Notice how the quotes are properly escaped and the separate lines are now concatenated together.

Now, suppose you wanted to parameterize some of the values in this string. For example, turn the “Sample Output” into a “text” parameter. How would you do that? Well, you should already know how. Just select the text, split the string, and promote it to a parameter.

Wrapping Up

If you’re not already using CodeRush, you should be. This post has covered only a portion of the tools and features that work with strings, and working with strings is only a very small tip of the very large iceberg of power that is CodeRush. CodeRush is the fastest, most powerful, and most memory-efficient developer productivity add-on available for Visual Studio.

The Extensible Test Runner You’ve Been Waiting For

Mark Miller (DevExpress) — Mon, 16 Nov 2009 21:36:37 GMT

We’ve been hard at work fine-tuning the CodeRush Test Runner, and we’re getting excited.

This screen shot contains a few clues as to why we’re so pumped up:

We’re pleased with the UI. Notice in the screen shot above how failing tests are easy to spot while the less-important information is rendered in a lower contrast that’s easy on the eyes. Also, we’ve done some work on the tree list to reduce the number of clicks needed to get to tests of interest. And there’s a handy filter text box at the top.

So it looks pretty. But more importantly, the Test Runner supports all the popular testing frameworks right out of the box, including VSTest, NUnit (including different flavors mixed in with various extensions), and the oft-neglected xUnit and MbUnit. The screen shot above is taken from a solution that includes test cases for all of these frameworks.

CodeRush customers will also receive full source code to the plug-ins we ship that provide all this luscious unit testing support. So if you want to extend support for any of these unit test frameworks, it’s easy. Or if you want to add support for a brand new unit testing framework, you all have the sample code you need to get started. That is cool.

Test results also appear in the code:

You can run test cases from the Test Runner, or from the code itself by clicking one of the Test Runner icons that appear next to the unit test attributes (as shown in the screen shot above).

The Test Runner debuts in CodeRush 9.3 (beta is internal testing and will available soon if not already by the time you read this). I’ll be showing the Test Runner at PDC in Los Angeles this week, so if you’re in LA stop by our booth and check it out.

Here's a Picture Worth 1000 Words...

Mark Miller (DevExpress) — Wed, 11 Nov 2009 21:55:00 GMT

Derek Reynolds says it all with a single screen shot.

DX Labs: Single Code Base Driving GDI and WPF Simultaneously from CodeRush Plug-ins

Mark Miller (DevExpress) — Mon, 19 Oct 2009 23:05:00 GMT

Since the beginning, CodeRush has been extensible.

The cardinal rule for extensible architectures:

New revs of the framework can’t break existing plug-ins.

Through each release the IDE Tools team responsible for CodeRush has strived to ensure backward and forward compatibility for 3rd-party plug-ins. And throughout the years, we have by and large achieved this goal.

And along comes the Visual Studio 2010 editor.

Based entirely on WPF.

Which kind of mucks things up for anyone writing plug-ins that paint on the editor. Those plug-ins rely upon DXCore events that pass a GDI Graphics instance which makes it easy to paint on the editor surface. But VS 2010 has effectively removed GDI from the equation.

Which leaves us with a few obvious options:

Split the code base (attempt to maintain two code bases)
Abandon GDI and support for GDI-based dev environments (e.g., VS 2008 and earlier)

The cost of splitting the code base is potentially very high, not only for us but also for customers. For us, it makes the code more complex to maintain, and it potentially creates a scenario where CodeRush customers remaining in VS 2008 or VS 2005 might go without issue fixes and enhancements occurring in the latest version of CodeRush working in WPF land. Moving to an entirely new code base has similar consequences for customers remaining in GDI land.

There is also a less obvious solution which is to provide a GDI layer on top of the WPF layer in VS 2010, which would allow editor-surface painting plug-ins written in VS 2008 to continue to work in VS 2010. I’m about as comfortable with this approach/hack as I am squeezing my pet elephant Jorge into my brand new bright yellow Borat-style bathing suit. While such a configuration may appear stylish from a distance and to some degree addresses the forward compatibility challenge, it brings the risk of some serious chafing. It just doesn’t fit in a WPF world where you want to be able to take advantage of everything that Microsoft has added to VS 2010 that works with WPF.

And so we’ve walked away from this more obscure option too.

So we continued to consider the problem.

Around this time I was working on a blog post on Implementing Code Providers, and this bit of code that shows up in the post was on my mind:

private void cpImplementUnimplementedProperty_PreparePreview(object sender, PrepareContentPreviewEventArgs ea)
{
Property oldProperty = GetProperty(ea.Element);
if (oldProperty == null)
return;

ElementBuilder elementBuilder = ea.NewElementBuilder();
string newCode = GetNewPropertyDeclaration(elementBuilder, oldProperty);

ea.AddCodePreview(oldProperty.Range.Start, newCode.Trim());
ea.AddStrikethrough(oldProperty.Range);
}

Notice the last two lines of code. These two lines of code add a visual strikethrough markup over the old code in the editor, and they also add a Code Preview window that’s attached to the code. Both of these look like this:

Notice the complete lack of anything even remotely resembling GDI whatsoever in those two lines of code. The GDI-heavy code to actually paint the strikethrough and the event handling necessary to support this are abstracted away from the plug-in already. This was all a result of work we did years ago to make it super easy to create preview hints for refactorings and code providers. (That’s why CodeRush includes over 185 refactorings – the architecture makes it super-easy to make them.)

Considering the strikethrough code example above eventually led us to this question:

Can we abstract all aspects of painting out to a layer that plug-ins can exploit to paint on the editor, without requiring explicit knowledge of GDI or WPF?

If you’re familiar with both GDI and WPF, you understand the magnitude of this question. At first glance it seems incredibly challenging. GDI painting is event-driven, and WPF painting is more of a one-time assembly of pieces, and changes to the pieces can result in automatic updates to the images. GDI has none of this. These drawing frameworks are so radically different in so many ways it seems impossible. Of course, on the IDE Tools team, we don’t use the word impossible. We might use “economically infeasible” and “No F*in’ Way”, but never impossible. So the question really became one of economic feasibility. Could we abstract enough of what we needed from these two drawing frameworks in time for the VS 2010 release?

The answer appears to be YES. To be clear, there are two steps here:

Abstract the painting layer, and create two different engines that map the abstraction to either WPF or GDI.
Update any existing source code that does anything remotely GDI so it uses the new painting layer.

Drawbacks:

We have to port GDI-specific code in existing plug-ins to the new framework. Third party developers using GDI to paint as well will also need to be ported if they want to work in VS 2010.

Benefits:

Single source code base as we move forward.
Plug-ins using the new painting layer are likely to work in all versions of Visual Studio that support .NET. If you’re a plug-in developer working with CodeRush or DXCore you don’t need to worry about which drawing framework or which version of Visual Studio you will support.

I find this quite exciting because it removes the weight from the decision of whether to work in WPF or to stay in GDI, and that may be a decision developers out there are facing.

Let’s take a look at a real example from the source code for the upcoming CodeRush 10 for VS 2010.

Disclaimer: This is a DevExpress Labs preview. Everything here is subject to change until we release!

The CodeRush stack-based markers feature paints a small triangle on the editor to indicate the position of markers dropped by the developer. Using the new framework, if we want to put something on the editor we start with a descendant of the CRVisualAdornment, like this:

public class CRMarkerAdornment : CRVisualAdornment
{
public CRMarkerAdornment(IElementFrame frame)
: base(frame)
{
}

public override void Render(IDrawingSurface surface)
{
    // TODO: Render the marker.
}

public override Size GetSize()
{
    return new Size(10, 10);
}
}

The GetSize override allows the adornment to tell the drawing engine how big it is. The Render method override is where we place the code that will actually draw the triangle. That code might look something like this:

public override void Render(IDrawingSurface surface)
{
    Point topPoint = new Point(5, 5);
    double halfBase = 2.5;
    double height = 5;

    Point[] points = {
                         new Point(topPoint.X, topPoint.Y),
                         new Point(topPoint.X - halfBase, topPoint.Y + height),
                         new Point(topPoint.X + halfBase, topPoint.Y + height)
                       };

    surface.DrawPolygon(_FillColor, _OutlineColor, points);
}

IDrawingSurface looks a bit like the GDI Graphics object. _FillColor and _OutlineColor are fields of type ColorProperty (more on this in a bit), and their declarations look like this:

ColorProperty _FillColor;
ColorProperty _OutlineColor;

We initialize these fields in our constructor:

public CRMarkerAdornment(IElementFrame frame)
: base(frame)
{
_FillColor = new ColorProperty(Colors.Blue);
_OutlineColor = new ColorProperty(Colors.DarkBlue);
}

ColorProperty is cool. If we use ColorProperties in the Render override, any changes to these values are automatically reflected in the editor, regardless of the platform we are rendering in.

So, for example, if we wanted to create a new transient marker with a short life span of 20 seconds, we could visually indicate that lifespan by changing the values of the ColorProperties over time (for example, changing the transparency of the color).

Let’s give our CRMarkerAdornment new properties so we can do just that:

public Color FillColor
{
    get { return _FillColor.Value; }
    set { _FillColor.Value = value; }
}
public Color OutlineColor
{
    get { return _OutlineColor.Value; }
    set { _OutlineColor.Value = value; }
}

Notice these exposed properties are of type Color, not ColorProperty.

And that’s it! Now we have a graphic element that paints in both WPF and GDI. I’m pretty sure this has never been done before. The full source looks like this:

public class CRMarkerAdornment : CRVisualAdornment
{
ColorProperty _FillColor;
ColorProperty _OutlineColor;

public CRMarkerAdornment(IElementFrame frame)
: base(frame)
{
    _FillColor = new ColorProperty(Colors.Blue);
    _OutlineColor = new ColorProperty(Colors.DarkBlue);
}

public override void Render(IDrawingSurface surface)
{
    Point topPoint = new Point(5, 5);
    double halfBase = 2.5;
    double height = 5;

    Point[] points = {
                         new Point(topPoint.X, topPoint.Y),
                         new Point(topPoint.X - halfBase, topPoint.Y + height),
                         new Point(topPoint.X + halfBase, topPoint.Y + height)
                       };

    surface.DrawPolygon(_FillColor, _OutlineColor, points);
}

public override Size GetSize()
{
    return new Size(10, 10);
}

public Color FillColor
{
    get { return _FillColor.Value; }
    set { _FillColor.Value = value; }
}
public Color OutlineColor
{
    get { return _OutlineColor.Value; }
    set { _OutlineColor.Value = value; }
}
}

By now you might be wondering what namespace holds the types Color, Point, Colors, and Size from the code above. In implementing this framework, we had three choices:

Use System.Drawing and convert to WPF types when we need to paint with WPF.
Use System.Windows and convert to GDI types when we need to paint with GDI.
Use a completely new set of types and convert those to the needed types when painting.

Choice #3 seems to clearly involve the most work. It means the GDI and WPF engines must each implement type conversion, so one might be inclined walk away from that option. However, the first two choices will penalize some customers, forcing both WPF and GDI assemblies to be loaded when only one is really necessary. So we went with choice #3.

So now we have a CRVisualAdornment descendant that paints a triangle on the surface of the editor. There are several ways to add this adornment to the editor. One way is to do something like this:

IElementFrame frame = ea.CreateFrame(new SourceRange(10, 20, 10, 21));

CRMarkerAdornment markerAdornment = new CRMarkerAdornment(frame);
markerAdornment.PenColor = Colors.Red;
markerAdornment.OutlineColor = Colors.DarkRed;

ea.AddAdornment(markerAdornment);

The “ea” in the sample code above represents the event arguments to an unspecified event handler. Adornments can be added in response to a number of IDE events, such as opening a document or scrolling. Adornments can also be added programmatically at any time. The first line in the code above creates a new IElementFrame implementer, which essentially marks a rectangular region in the code using lines and columns. So this marker starts on line 10 at character 20, and runs to character 21 on that same line. Passing the IElementFrame implementer to our CRMarkerAdornment constructor allows the Marker to automatically stick to the code, so when you scroll the marker will scroll too.

Miller on DNR TV -- Intelligent Code Generation in Visual Studio with CodeRush

Mark Miller (DevExpress) — Tue, 06 Oct 2009 17:57:00 GMT

I'm deep in code and surfacing briefly only to mention this DNR TV session I recorded with Carl Franklin. The session gives you a taste of how to create language-independent intelligent code generators inside Visual Studio that work with CodeRush or CodeRush Xpress. For anyone who prefers watching a movie over reading DXCore plug-in tutorial blog posts, this one's for you:

http://www.dnrtv.com/default.aspx?showNum=152

For developers interested in creating refactorings instead of code providers, just drop a RefactoringProvider onto your form instead of the CodeProvider -- all other steps remain the same.

Note: The source is available as a link at the bottom of the DNR TV page. This source includes extension methods for anyone working in a version of CodeRush earlier than 9.27. If you're using 9.27 or higher, those extension methods are redundant. Check out the source even if you watch and follow the video, because it includes additional functionality not covered in the video.

Miller on Hanselminutes

Mark Miller (DevExpress) — Fri, 04 Sep 2009 20:46:00 GMT

I sat down with Scott Hanselman this week and discussed CodeRush architecture, breaking the rules, and my allegedly massive head.

Get it here:

http://www.hanselminutes.com/default.aspx?showID=196

CodeRush Test Runner In-source UI Preview

Mark Miller (DevExpress) — Wed, 02 Sep 2009 19:48:00 GMT

Lately I've had my head deep in code, and Mehul has done me the favor of blogging about our new Test Runner, in development. See Mehul's blog post for a preview of the new Test Runner in-source UI.

Code Providers 101 -- Implementing Unimplemented Properties

Mark Miller (DevExpress) — Thu, 23 Jul 2009 15:12:00 GMT

Here's another article on writing plug-ins based on the DXCore. This plug-in is based on a request from the Refactor! Pro newsgroups, which goes like this:

Whenever I choose to automatically implement an interface, a property that throws NotImplementedException in the getter and setter appears. For example:

        public int Foo
        {
            get
            {
                throw new NotImplementedException();
            }
            set
            {
                throw new NotImplementedException();
            }
        }

It would be great if there was a refactoring that let me turn this into an auto property, or a backing field property. I know this technically isn't a "refactoring" since it's actually causing the functionality of the code to change, but I find myself running into this quite a bit.

This is a great request, in fact, so good, we implemented a feature similar to this for CodeRush 9.1. So for those of you who already have CodeRush 9.1 or above, this tutorial will serve as a how-to for creating tools that generate code intelligently. For the rest of you, this tutorial will have the added benefit of producing a useful feature you can add to your Visual Studio toolset.

As the author mentions, this feature technically isn't a refactoring. That's okay, because although Refactor! Pro is all about refactoring, CodeRush includes a sweet mechanism for changing code (in ways that might result in a change to program behavior), called CodeProviders. CodeProviders are very similar to RefactoringProviders, the primary distinction is how they are presented to developers in the CodeRush/Refactor menu. For example:

In the screen shot above the CodeRush/Refactor! menu is divided into two sections. The top section in red lists refactorings, while the lower section in blue lists code providers. This visual distinction alerts developers that menu items in blue may change program behavior.

So while it might be considered bad form to create a refactoring that converts an unimplemented property into an implemented one, adding this feature as a CodeProvider makes all the sense in the world. So let's do that.

Getting Started

From the DevExpress menu, select New Plug-in....

I'm calling this plug-in project CR_ImplementProperty. I like to start all my CodeRush plug-ins with the CR_ prefix, and I should point out that because this plug-in is based on the CodeProvider technology, developers will need CodeRush to try it out.

Click OK. The DXCore Plug-in Project Settings dialog will appear.

We can simply accept the default options on this dialog and click OK.

The project will load and the plug-in design surface will be activated.

Dropping the CodeProvider

From the Toolbox, navigate to the DXCore tab and select the CodeProvider control.

Note: If you don't see this control you can add it by right-clicking the Toolbox, selecting "Choose Items...", and then placing a check next to the CodeProvider control in the DevExpress.CodeRush.Core namespace.

Double-click the CodeProvider control in the Toolbox to drop it on the plug-in design surface.

Now let's change the following properties of this CodeProvider:

Property	Value
(Name)	cpImplementUnimplementedProperty
AutoUndo	True
Description	Implements an unimplemented property.
DisplayName	Implement Property
ProviderName	ImplementUnimplementedProperty

Switch to the Events page of the Properties grid.

First we need to tell the system that our CodeProvider is available. We can add that logic in a handler for the CheckAvailability event.

I want this CodeProvider to be available when the caret is inside a property declared like this:

        public int Foo
        {
            get
            {
                throw new NotImplementedException();
            }
            set
            {
                throw new NotImplementedException();
            }
        }

or this:

        public int Foo
        {
            get
            {
                throw new NotImplementedException();
            }
        }

or this:

        public int Foo
        {
            set
            {
                throw new NotImplementedException();
            }
        }

Normally when write plug-ins that work with source code, we break out the Expressions Lab. The Expressions Lab reveals the structure of the language-independent tree that represents the source code inside Visual Studio.

However, instead of starting with the Expression Lab immediately, it might be interesting to see how far we can get using only Visual Studio's Intellisense and a bit of knowledge learned from previous ventures with the Expressions Lab.

From past lessons we know that every element in the parse tree (e.g., for-loops, expressions, primitives, variables, methods, classes, etc.) either descends from LanguageElement or implements IElement. LanguageElement and many of its descendants are located in the DevExpress.CodeRush.StructuralParser namespace. For example, inside this namespace, there is a class called Property which represents property declarations in source code.

The ea argument to the CheckAvailability event includes a property called "Element", and this generally refers to the active element at the caret. By the way, this Element can also be set programmatically by plug-ins wishing to remotely invoke a refactoring or a code provider, so it is possible that this Element may actually be different from the element at the caret. So we need to resist the urge to use CodeRush.Source.ActiveProperty (which we've seen in other plug-ins in the past) because while that may work when the caret is actually in the property, checking ActiveProperty is likely to produce unexpected results if this CodeProvider is invoked remotely for a different property somewhere else in the code.

So, if Element is a Property, we expect to eventually drill down into its accessors to see if they contain a Throw, passing a NotImplementedException.

However if Element refers to a starting code element inside the property (such as the get accessor, for example), then it makes sense to find the parenting Property so we have a consistent starting point. This allows the CodeProvider to be available even when the caret is inside the unimplemented property declaration. Having a wider range of where the feature is available makes it easier to discover.

So for the purposes of identifying unimplemented properties, it is important to get a consistent starting point, regardless of whether ea.Element refers to the property or a child element of the property.

Here's the code I use to get to that Property starting point:

Property property = ea.Element as Property;
if (property == null)
property = ea.Element.GetParentProperty();

We're likely to need this later when we apply this code provider to make changes to the code, so let's place this code in its own method, like this:

private static Property GetProperty(LanguageElement element)
{
Property property = element as Property;
if (property == null && element != null)
property = element.GetParentProperty();
return property;
}

With that in place, my event handler now looks like this, containing two calls to a method named IsUnimplemented, which we'll create in a moment:

private void cpImplementUnimplementedProperty_CheckAvailability(object sender, CheckContentAvailabilityEventArgs ea)
{
Property property = GetProperty(ea.Element);
if (property == null)
    return;
if (property.HasGetter && !IsUnimplemented(property.Getter))
    return;
if (property.HasSetter && !IsUnimplemented(property.Setter))
    return;
ea.Available = true;
}

The IsUnimplemented method is going to take the Getter or the Setter accessor, and find the first child statement and see if it's a Throw statement. IsUnimplemented looks like this:

private static bool IsUnimplemented(PropertyAccessor accessor)
{
LanguageElement firstChild = accessor.GetFirstCodeChild();
if (firstChild == null)
return true;
if (firstChild.ElementType != LanguageElementType.Throw)
return false;
return Throws(firstChild as Throw, "NotImplementedException");
}

The call to the GetFirstCodeChild() method returns the first LanguageElement that is a child of the accessor that is not a comment. Note that right after this call there's a check to see if that firstChild is null, and if so, IsUnimplemented returns true. That means our CodeProvider will also be available in these declaration scenarios (not all of which compile):

        public int Foo
        {
            get
            {
            }
            set
            {
            }
        }

And this:

        public int Foo
        {
            get
            {
            }
        }

And this:

        public int Foo
        {
            set
            {
            }
        }

After that, the IsUnimplemented method compares the ElementType of the firstChild against the enum LanguageElementType.Throw. This is done for efficiency -- it's faster than comparing against the Throw class itself, and a quick way to get out of the IsUnimplemented method for the majority of Property scenarios that are in fact implemented. Performance in availability checks is something we want to maximize for CodeProviders and RefactoringProviders.

The last call in IsUnimplemented is to a method called Throws, which needs to return true if the name of the exception thrown actually matches the one passed in.

And now let's bring in the Expressions Lab. When using the Expressions Lab to write code that can find structures, I usually place samples of those structures right inside the plug-in code I'm working on, usually inside a method that is never called. This makes exploring the structure and writing code to detect that structure fast and easy. So for this example, I'll add this line to the code:

throw new NotImplementedException();

And then check the result inside the Expressions Lab:

This three-level structure starts with a Throw object, which parents a DetailNode (in blue). That DetailNode is an ObjectCreationExpression, which in turn has a regular child node (in black) that is a TypeReferenceExpression. That TypeReferenceExpression has a Name property set to "NotImplementedException". If you click on each of these three nodes inside the Expressions Lab, you can see interesting values for the properties these nodes declare. For example, if you click on the Throw node, you can see that it has an Expression property described as "new NotImplementedException()", which happens to be the first detail node that you see in blue, above. Often you will find properties like this Expression property, which are there simply to make it easier to access the blue detail nodes of the element.

So based on this exploration, I can create a Throws method that looks like this:

private static bool Throws(Throw throwStatement, string exceptionName)
{
if (throwStatement == null)
    return false;

ObjectCreationExpression expression = throwStatement.Expression as ObjectCreationExpression;
if (expression == null)
    return false;

TypeReferenceExpression typeRef = expression.ObjectType;
if (typeRef == null)
    return false;

return typeRef.Name == exceptionName;
}

Now it's time to test. We haven't written any code yet to actually fill in the missing implementation for the property. We've only written code to see if our CodeProvider should actually be available. So when we test, we're really only testing the availability check.

Compile and Run. A second instance of Visual Studio will start. In that instance, open a source code file that contains an unimplemented property (you might want to create a dedicated test file or project for this), and move the caret so it rests inside that property, and then press the CodeRush/Refactor! key (e.g., Ctrl+`). The Refactor/Code menu will appear, and it should look something like this:

And so here we can see our Implement Property CodeProvider is now available in the Code menu. Notice the description added previously now appears inside the light yellow hint to the right.

Now move the caret to a fully-implemented property (e.g., something with backing store), and press the CodeRush/Refactor! key to verify that in this location the Implement Property CodeProvider does not appear on the Refactor/Code menu.

Excellent!

We're getting closer. The next step is to generate the source code for a new replacement property along with appropriate backing store. This is where things get interesting.

Generating the Implemented Property

We've already seen that when you're creating plug-ins that work with source code, it is possible to deal with that code in a language-independent manner. This means that with the code we've written so far, we would expect to see our Implement Property CodeProvider appear in any other language that supports properties, such as Visual Basic.

It makes sense to have the replacement property generated in a similar language-independent way, so this works regardless of what programming language is active inside of Visual Studio.

If the second instance of Visual Studio is still running, you can close that down.

Let's handle the Apply event. This event will be fired when you select "Implement Property" from the Code menu. To handle this event, back in the original instance of Visual Studio, activate the PlugIn1.cs [Design] surface, click the cpImplementUnimplementedProperty control, and then on the Events page of the Properties grid, double-click on the Apply event to create a new handler.

The DXCore supports language-independent code generation through a number of API access points, the most robust of which is an ElementBuilder. One of the cool things about the DXCore, is that many of the events pass specialized EventArg descendants filled with useful methods and properties. One of the methods passed through the ApplyContentEventArgs is the NewElementBuilder method. This method creates a new instance of an ElementBuilder, one dedicated to building parse trees for the active language. You can also get an ElementBuilder from the CodeRush.Language service.

Inside the Apply event handler, type in "ea.", and then select the "NewElementBuilder" method.

Add the missing parens and the semi-colon (tip: just press the open paren key and then the semi-colon -- CodeRush will add the closing paren and place the semi-colon outside the parens).

Next, press the CodeRush/Refactor! key and select Declare Local.

And you'll get a line of code looking like this:

ElementBuilder newElementBuilder = ea.NewElementBuilder();

By the way, Declare Local, a feature that you've likely seen in CodeRush already, is a CodeProvider, just like the feature we're building now.

Now that we have our ElementBuilder, let's add some elements. But to do this we need more information about the property we'll be creating. For example, we need to know its type, its name, and whether it has a getter and/or a setter. We can get all that information from the property we're replacing. How can we get to the property structure so we can query it? We can simply call that GetProperty method we added before, passing in the ea.Element:

Property oldProperty = GetProperty(ea.Element);

The ea argument for the Apply event also includes an Element property. Cool.

OK, so now we have a reference to the oldProperty (the one we'll be replacing), and we have an ElementBuilder. Based on these two, I now have an Apply event handler that looks like this:

private void cpImplementUnimplementedProperty_Apply(object sender, ApplyContentEventArgs ea)
{
Property oldProperty = GetProperty(ea.Element);
if (oldProperty == null)
return;
ElementBuilder elementBuilder = ea.NewElementBuilder();
string newCode = GetNewPropertyDeclaration(elementBuilder, oldProperty);
ea.TextDocument.Replace(oldProperty.Range, newCode, "Implement Property", true);
}

We'll discuss the last line of code in this method a little later. For now we'll focus on the call to GetNewPropertyDeclaration.

The GetNewPropertyDeclaration method needs to generate a new property declaration based on the oldProperty. This method needs to generate a new property based on the existing one, replacing the calls to throw exceptions with real code that accesses the backing store of a field variable. Let's take this method a piece at a time, and then at the end we'll see the whole thing as a single method.

First, we need to get the name and type of the property to declare, as well as an appropriate name for the field variable. That code looks like this:

private static string GetNewPropertyDeclaration(ElementBuilder elementBuilder, Property oldProperty)
{
string propName = oldProperty.Name;
string typeName = oldProperty.GetTypeName();
string fieldVariableName = CodeRush.Strings.Get("FormatFieldName", propName);
...
}

The most interesting line of code here is the the call into CodeRush.Strings.Get. This is turn makes a call into a StringProvider named "FormatFieldName". This StringProvider formats the passed-in parameter (propName) so it matches your style for field declarations. You can change the style for identifiers in the Editor\Code Style\Identifiers options page.

By the way, this StringProvider is used in a number of templates, including templates that generate properties with backing store. You can find documentation for this and other StringProviders in the CodeRush User Guide, in the Reference\String Providers section.

Here's what you will see when you click the FormatFieldName link:

Next, we need to add the backing store declaration to the elementBuilder, like this:

Variable fieldVar = elementBuilder.AddVariable(null, typeName, fieldVariableName);
fieldVar.IsStatic = oldProperty.IsStatic;

So the AddVariable method on ElementBuilder generates a tree structure that looks like this:

It's a Variable named "_Foo" (or whatever value you pass in through fieldVariableName) with a DetailNode that is a TypeReferenceExpression named "int" (or whatever value you pass in through typeName). When generated, this tree structure will become this in C#:

int _Foo;

Next we need to add the property declaration to the elementBuilder, like this:

Property newProperty = elementBuilder.AddProperty(null, typeName, propName);
newProperty.Visibility = oldProperty.Visibility;
newProperty.IsStatic = oldProperty.IsStatic;
newProperty.IsVirtual = oldProperty.IsVirtual;
newProperty.IsOverride = oldProperty.IsOverride;
newProperty.IsExplicitInterfaceMember = oldProperty.IsExplicitInterfaceMember;

ElementBuilder's Add methods create the specified element and then add that element to the specified parent (the first parameter to the AddXxxxxxx methods). In both of these cases so far, the first parameter passed in was null, which means these elements will be added to ElementBuilder's TopLevelElements collection. Later, when we call ElementBuilder's GenerateCode method, code will be generated for all the LanguageElements contained in the TopLevelElements collection.

Notice also in the code above how we can modify the references returned by ElementBuilder's AddXxxxxx calls. ElementBuilder's AddProperty method generates a tree structure that looks like this:

It's a Property named "Foo" (or whatever value you pass in through propName) with a DetailNode that is a TypeReferenceExpression named "int" (or whatever value you pass in through typeName). This Property element does not yet have a getter or a setter, so let's add those code blocks to the newProperty reference (the local variable that gets the result of the AddProperty call).

Here's code to add the getter:

if (oldProperty.HasGetter)
{
Get getter = elementBuilder.AddGetter(newProperty);
elementBuilder.AddReturn(getter, fieldVariableName);
}

By storing the result of an ElementBuilder.AddXxxxxx call, and then later passing that LanguageElement back in as the parent (first argument) in subsequent ElementBuilder.AddXxxxxx calls, we are able to generate hierarchical structures to match the code we want. The call to AddReturn, above, generates a return statement returning the passed-in fieldVariableName. The tree for the getter looks like this:

And corresponds to code like this in C#:

get
{
return _Foo;
}

Next we'll add the setter, if necessary:

if (oldProperty.HasSetter)
{
Set setter = elementBuilder.AddSetter(newProperty);
elementBuilder.AddAssignment(setter, fieldVariableName, "value");
}

The call to AddAssignment, above, creates a statement that assigns "value" to the fieldVariableName. The tree for this segment looks like this:

So far, the tree we've built using the ElementBuilder looks like this (with _Foo, Foo, and int being replaced with the values you've passed in for field variable name, property name, and type name respectively):

Finally we can get all of the generated code as a string so we can insert it into the document, by calling GenerateCode:

return elementBuilder.GenerateCode();

The entire method looks like this:

private static string GetNewPropertyDeclaration(ElementBuilder elementBuilder, Property oldProperty)
{
string propName = oldProperty.Name;
string typeName = oldProperty.GetTypeName();
string fieldVariableName = CodeRush.Strings.Get("FormatFieldName", propName);

Variable fieldVar = elementBuilder.AddVariable(null, typeName, fieldVariableName);
fieldVar.IsStatic = oldProperty.IsStatic;

Property newProperty = elementBuilder.AddProperty(null, typeName, propName);
newProperty.Visibility = oldProperty.Visibility;
newProperty.IsStatic = oldProperty.IsStatic;
newProperty.IsVirtual = oldProperty.IsVirtual;
newProperty.IsOverride = oldProperty.IsOverride;
newProperty.IsExplicitInterfaceMember = oldProperty.IsExplicitInterfaceMember;

if (oldProperty.HasGetter)
{
    Get getter = elementBuilder.AddGetter(newProperty);
    elementBuilder.AddReturn(getter, fieldVariableName);
}

if (oldProperty.HasSetter)
{
    Set setter = elementBuilder.AddSetter(newProperty);
    elementBuilder.AddAssignment(setter, fieldVariableName, "value");
}

return elementBuilder.GenerateCode();
}

Before we test this, let's look at that last line of code in our Apply event handler:

ea.TextDocument.Replace(oldProperty.Range, newCode, "Implement Property", true);

This line calls Replace on the active TextDocument. Replace accepts a SourceRange of code to replace (in this case, the oldProperty), the newly-generated code, a display string to describe the operation (for the undo/redo stack), and an optional parameter to specify whether the newCode we pass in should be formatted or not. Visual Studio's active language service (e.g., C#, Visual Basic, etc) performs the formatting based on formatting options you've defined for that language in the Visual Studio options dialog. In most cases you will want to pass in true for this last parameter, as that will ensure the generated code is properly indented and matches the coding styles defined in Visual Studio.

And that wraps up the explanation of the code needed to generate the implemented property. It's time to test once again.

Testing Code Generation

Click Run. In the second instance of Visual Studio, find an unimplemented property and press the CodeRush/Refactor key to apply this CodeProvider.

Starting with this sample code in C#...

public int Foo
{
get
{
throw new NotImplementedException();
}
set
{
throw new NotImplementedException();
}
}

After applying Implement Property I get this:

int _Foo;
public int Foo
{
get
{
return _Foo;
}
set
{
_Foo = value;
}
}

Nice!

Undo and Redo

Notice also right after applying this CodeProvider, the top entry in the undo stack reads "Implement Property":

The undo entry has been added for us automatically through the call to TextDocument.Replace.

Adding a Preview Hint

The only thing missing to make this a professional-grade CodeProvider is a preview hint. Preview hints show what will happen before the menu item is selected. For example, here's the preview hint for Extract Method for a selection inside our GetNewPropertyDeclaration method:

Let's add that now. Close down the second instance of Visual Studio if it's still running. Activate PlugIn1.cs [Design] and select the cpImplementUnimplementedProperty CodeProvider.

Double-click the PreparePreview event to create a handler....

The PreparePreview event is fired whenever the mouse hovers over an item in the CodeRush/Refactor menu, or when the keyboard is used to highlight entries and an entry has been highlighted for more than a few moments. So when this event fires your CodeProvider has already determined that it is available. So the sequence of events usually looks like this:

CheckAvailability -> PreparePreview -> Apply

Note that it can also be like this if the menu item is selected very quickly or if only one refactoring or code provider is available:

CheckAvailability -> Apply

And it can also be like this if a refactoring or code provider is invoked programmatically by another plug-in:

Apply

The code for our PreparePreview event handler looks like this:

private void cpImplementUnimplementedProperty_PreparePreview(object sender, PrepareContentPreviewEventArgs ea)
{
Property oldProperty = GetProperty(ea.Element);
if (oldProperty == null)
return;

ElementBuilder elementBuilder = ea.NewElementBuilder();
string newCode = GetNewPropertyDeclaration(elementBuilder, oldProperty);

ea.AddCodePreview(oldProperty.Range.Start, newCode.Trim());
ea.AddStrikethrough(oldProperty.Range);
}

Notice starts off similarly to the code in our Apply event handler. We get the Property to refactor, and get the source code that will replace it. The most interesting part of this handler are the last two lines.

The first, a call to AddCodePreview, creates a floating window containing the specified source code with a small arrow which points to the specified SourcePoint (in this case the start of the oldProperty).

The last line calls AddStrikethrough, which crosses out the code within the specified range.

Run and test. You should get something like this:

Language Independence

In the CodeProvider we just built you'll notice that we didn't write any code specific to any particular programming language. We just built the tree we wanted to generate using the ElementBuilder. As a result, this CodeProvider will work in any language supported by the DXCore (any language that also supports properties, classes, and field variables). To prove this, open up a Visual Basic file and try it out. You should see something like this:

That's it! I hope this helps make it easier for you to add your own refactorings and code providers to the DXCore! Let me know if you have any questions or would like to see more tutorials like this in the future.

What's New in CodeRush 9.2

Mark Miller (DevExpress) — Wed, 15 Jul 2009 22:20:00 GMT

Here's what you can expect in the CodeRush 9.2 release.

Faster Performance

A new symbol cache, built the first time you open a solution improves the speed of subsequent solution parses dramatically. Now the speed to go from opening a solution to being able to refactor anywhere in that code base increases by 200%-500% for large solutions. More details on the performance improvements can be found here.

Additional performance enhancements:

First startup after install is now significantly faster -- plug-in profile data now ships with the install and the plug-in profiling step is no longer part of the first startup.
Background parsing, if running, is now suppressed during a solution build.
Plug-in loader engine performance has been improved.
The time to find all references has been reduced.
Code issue checking time has been reduced.
Incremental parser performance has been improved.
Visual element painting time has been reduced.
Availability checks for code providers are now executed in less time.

Reduced Memory Consumption

CodeRush 9.2 uses dramatically less memory. Project symbols are now cached, and only loaded when needed. Recently-accessed members are kept in memory, while stale members are aggressively released. As a result, customers with large solutions can expect reductions in overall memory consumption by 100MB-200MB. More details on the memory savings can be found here.

Manual Load and Unload

Normally CodeRush loads on startup, and unloads when Visual Studio shuts down. CodeRush 9.2 adds the ability to defer loading to another time after startup, and also adds the ability to unload CodeRush while Visual Studio remains running. This may be useful for developers running into memory issues (e.g., very large solutions open in many instances of Visual Studio).

You can defer the CodeRush startup time to a time of your choosing on the CodeRush Startup options page. Check the "Load manually" checkbox and restart.

The next time Visual Studio starts, there will be a DevExpress menu item with a single entry, "Load". Selecting this entry will load CodeRush and any other third-party plug-ins that rely upon the DXCore.

Settings Merge on Upgrade

With this release we introduce a new XML storage engine for CodeRush settings. This settings engine is backwards compatible - customer settings stored in the older INI files are merged with new settings stored in XML files (the INI files are not deleted). This engine will allow DevExpress to enhance default settings without losing customer changes.

Support for Preprocessor Directives

Conditional compiler directives are now supported.

Background Processing Progress Bar

CodeRush now shows progress for background parsing and symbol loading as you open a new solution. This progress bar is essentially your countdown to the moment when you can refactor instantly anywhere in the code. Note that you can work normally with Visual Studio before the background parse process ends. Closing this window does not break the background parsing process.

DXCore Version Switcher

The DXCore Version Switcher lets you switch among several versions of DevExpress IDE Tools installed side-by-side.

CodeRush Xpress for C# and Visual Basic inside Visual Studio 2008

Mark Miller (DevExpress) — Thu, 25 Jun 2009 20:00:00 GMT

CodeRush Xpress is a powerful developer productivity tool from Dev Express. The product is free, licensed by Microsoft on behalf of all developers working in Visual Studio 2008 in all paid-for product skus (e.g., Standard, Professional, Team System). Note however that CodeRush Xpress will not load in the Express Editions of Visual Studio.

CodeRush Xpress includes features that support common developer tasks in the following areas:

CodeRush Xpress fully supports all language features of Visual Basic and C# in Visual Studio 2008. If a specific feature applies to only one of these two languages, it will be noted with one of these icons:

More details on CodeRush Xpress functionality follow.

Navigate

CodeRush Xpress includes seven powerful navigation features to make getting to that important location fast and easy.

Camel Case Navigation

You can move among the lowercase-to-uppercase transitions using Camel Case Nav.

To move right, hold down the Alt key and press the Right arrow key inside a camel case identifier.

To move left, hold down the Alt key and press the Left arrow key inside a camel case identifier.

Camel Case Nav is useful when you want to rename an identifier and change the name in a manner that keeps a portion of the existing camel case identifier. For example, if an existing identifier was called "StartTasks" and you wanted to rename it to "StartFilteredTasks", you could use Camel Case Nav to instantly get the caret between the "Start" and "Tasks" parts before typing in the new part.

Collect Marker

Whenever a CodeRush Xpress feature takes you to a new place in the code, CodeRush Xpress drops a stack-based marker at the original location. You can return to the original location (collecting the marker and popping it off the stack) by pressing Escape (when no other tool tip windows or context menus are active).

When you press Escape, CodeRush Xpress animates a small locator beacon around the marker. This locator beacon is useful when your eyes are looking elsewhere on the screen, especially if you work with a large monitor. CodeRush Xpress also attempts to shift the code vertically so its position is roughly equivalent to what it was when you last viewed it.

Structural Highlighting

Structural Highlighting helps you visually navigate the structure of the code. Matching delimiters are connected with low-contrast lines that are easy to read when this information is useful, and easy to ignore when your mind is on the code.

Structural Highlighting is useful for understanding the flow of large methods or third-party C# code using a different leading brace position than you might otherwise work with.

Tab to Next Reference

You can quickly jump to the active identifier's next reference in the solution file by pressing the Tab key (as long as the caret is somewhere inside the identifier). All matching references (and declaration) to this identifier will be underlined and the selection will move to the next reference. Continuing to press the Tab key will cycle through all identifiers in the solution. Shift+Tab brings you back. You can also press Escape to return to the starting location (where the Tab to Next Reference feature was first invoked on this identifier).

Tab to Next Reference is useful when you want to quickly visit all references to a particular identifier or type.

Highlight All References

Highlight All References is visually similar to Tab to Next Reference, however it does not move the caret. Just press Ctrl+Alt+U to see all references to the active identifier.

Quick Navigation

Quickly find a type, member, class, field or variable using Quick Nav. Just press Ctrl+Shift+Q to bring up the Quick Navigation window.

You can filter the list by entering a portion of the identifier text you are looking for. If you hold down the Shift key and enter uppercase letters, you can find all identifiers named with those uppercase letters, as in the example below:

You can preview the target location by holding down the Ctrl key. To jump to the selected symbol, press Enter. To return to the starting location, press Escape.

Quick File Navigation

Quickly find and open any file in your solution. Just press Ctrl+Alt+F to bring up the Quick File Navigation window. The filtering mechanism in this window is similar to what we've just seen in the Quick Navigation window. Just enter a few letters from the file name. CodeRush Xpress will filter down the list. Use the Up and Down arrow keys to select the file you want to jump to, and press Enter to go there (or Escape to close the Quick File Navigation window and return to where you were).

Select

CodeRush Xpress includes five intelligent features for selecting code more efficiently.

Camel Case Select

If you need to select one or more words from inside a camel-case identifier, just use the Shift key along with the Camel Case Nav keys.

For example, to select from the caret to the start of the camel case part to the left, use Alt+Shift+Left.

Selection Increase

First, there is a command to increase the selection by logical blocks. For example, if the caret is inside an expression, you can quickly expand the selection so it entirely holds the expression. Being able to quickly define a selection around a logical block is useful for refactoring. You can also use it to quickly select code you want to move to another location. This command is bound to a shortcut: Alt+Shift+=.

Selection Reduce

If you accidentally overshoot the block you want to select, you can reduce the selection by logical blocks using Alt+Shift+-.

Intelligent Cut, Intelligent Copy, and Paste Replace

If you need to cut or copy an identifier to the clipboard, there's no need to select it with CodeRush Xpress. Just place the caret on the identifier and press the cut or copy key (e.g., Ctrl+X, Shift+Delete, Ctrl+C, or Ctrl+Insert). CodeRush Xpress will select the identifier before the cut or copy operation.

Once you have an identifier on the clipboard, you can move the caret to a different identifier and replace it with the one on the clipboard using Ctrl+B. This Paste Replace command will select the identifier at the caret before pasting in the contents of the clipboard.

If you need to cut or copy a larger structure, such as a for loop, a try/finally block, a member or a class, just place the caret at the start of the block you want to copy and press the cut or copy key. CodeRush Xpress will select the entire block before cutting or copying the block to the clipboard.

Declare

CodeRush Xpress includes powerful features to intelligently declare classes, members, fields, local variables and so much more.

Consume-first Declaration

The consume-first declaration features of CodeRush Xpress are a quick way to generate the code you need. It starts with a call or a reference to something that doesn't exist yet (the consumption code). Just move the caret to the reference that needs to be declared and press the CodeRush key (Ctrl+` by default). CodeRush Xpress will do the rest, declaring the missing member, type, enum, or variable.

Consume-first declaration is useful because it gets you thinking in terms of developers who would consume the code you write. This can improve the quality of the code and make it easier for developers to work with your code. Consume-first declaration is also almost always an essential component of Test Driven Development (TDD).

However one of the most significant benefits of consume-first declaration is the efficiency gain -- you can quickly craft the code you need significantly faster than doing the same by hand.

To illustrate, let's look at a practical example. Often developers will use Intellisense to discover the return type of an unfamiliar method call or property, by entering that expression right inside the code, like this:

Typically what happens next is the developer's eyes move to the front of the tool tip and note the type (circled in red above). Then the developer accepts the suggestion and moves the caret to the beginning of the line to enter a variable declaration of the correct type (e.g., a variable of type "Module[]" in this example).

Overall there's a great deal of caret movement and typing involved just to declare a variable. To save a little time, some developers avoid specifying the type to implicitly declare variables (using the var keyword in C#, for example), thus avoiding the discovery and text entry costs associated with explicit declaration.

Fortunately, CodeRush Xpress makes it easy to explicitly declare variables in a way that exploits the power of Visual Studio's Intellisense and is likely to be highly compatible with how you already work:

Create the expression fragment on an empty line using Intellisense or simply typing the expression by hand.

If you're working in C#, there is no need to end the expression with a semi-colon.
With the caret at the end of the line, press the CodeRush key (Ctrl+`) and select "Declare Local" from the menu. CodeRush Xpress will generate the local variable declaration and select the variable so you can give it a meaningful name:

So the steps behind exploiting consume-first features are:

Write the call or reference to the member, type or variable that doesn't exist, OR enter an expression on an empty line (as in the example above).
Place the caret on the part that doesn't exist.
Press the CodeRush key (Ctrl+`). If a menu appears select the item you want to declare. For methods and properties, you may also see a horizontal red line appear (called the Target Picker) that allows you to select the insertion point for that member. Just use the up and down arrow keys to select the ideal location and press Enter to insert the declaration.
Sometimes CodeRush Xpress will shift the view or take you to another file, to show you the code just inserted. This allows you to rename or edit the newly-declared code. When you're satisfied with the declaration you can press Escape to collect the marker and return to where you started.

More details on specific consume-first declaration features follow:

Declaring Members

Want to add a member to a type? Just write the code as you would like it to appear. If it's a method, pass in the parameters you need (tip: if you're passing in parameters that are undeclared, declare those first before declaring the method). Place the caret on the member and press the CodeRush key.

Here are the consume-first member declarations you get with CodeRush Xpress:

Declare Constructor
Declare Method
Declare Property
Declare Property (auto-implemented)
Declare Property (with backing field)
Declare Getter
Declare Setter
Declare Event Handler

Declaring Types

To declare a new type, add a reference to it. Usually when you want a new type, you also want a constructor for it. So it's usually most efficient to enter the constructor call like on an empty line:

At this point you can press the CodeRush key (Ctrl+`) to declare a new local variable as we've seen before. You can also place the caret on the "FileLogger" text and press the CodeRush key to declare a class or struct.

Here are the consume-first type declarations you get with CodeRush Xpress:

Declare Class
Declare Delegate
Declare Enum
Declare Enum Element
Declare Interface
Declare Struct

Declaring Variables

As we've already seen, declaring variables to represent an expression on a line is easy. Another way to declare variables is to simply place the caret on a reference to the variable name in an assignment, as in the "_StartTime" text in the assignment below:

Press the CodeRush key (Ctrl+`) and select the declaration you'd like. A preview hint will let you see the changes to the code before you commit.

Here are the consume-first variable declarations you get with CodeRush Xpress:

Declare Field
Declare Local
Declare Local (implicit)

Create Method Contract

Often inside methods, before you work with the parameters, you need to verify that those parameters are valid. Developers typically select one of three mechanisms to ensure the data coming in is correct:

Throw an exception
Call Debug.AssertXxxx()
Exit the method

Regardless of which one of these you prefer, CodeRush Xpress makes it easy to build this contract code. Just move the caret to the start of the method, like this:

Then press the CodeRush key (Ctrl+`). The Create Method Contract menu will appear, allowing you to select the ideal mechanism for validating any parameters that are without validation code.

The preview hint shows you exactly what you're going to get. Create Method Contract makes the process of ensuring parameters are valid fast and easy.

Duplicate Line

Duplicate line lets you create a new line of code based on an existing line of code. You can duplicate variable declarations, constants, and method calls. The shortcut is Shift+Enter. For example, if the caret is on a declaration like this in C#:

Pressing Shift+Enter will create a duplicate declaration that looks like this:

Now it's simply a matter of typing in the new field name. Note that the Camel Case features , shown above, may be useful here if you want to change only a portion of the name (for example, changing _StartTime to _EndTime would be easy with Camel Case Nav and Camel Case Select).

Refactor

Refactoring is a powerful way to improve the quality and flexibility of your code, without changing program behavior. Well-refactored code costs less to maintain, is easier to extend, and is a more valuable asset than code that is allowed to accumulate technical debt (also referred to as design debt).

CodeRush Xpress includes over 50 refactorings, and nearly all work in both C# and Visual Basic. A few refactorings are available in only a single language due to features of that particular language.

For example, Inline With Statement and Create With Statement are both available in Visual Basic.

Similarly, refactorings to Add Block Delimiters and Remove Block Delimiters are only available in C#.

In some cases CodeRush Xpress provides wrappers for existing refactorings in either language. These wrappers ensure a more complete experience, making all refactorings contextually available in one location, accessed from a single keystroke (Ctrl+`). In many cases wrappers will also implement a preview hint, so you can see the impact of the changes before you commit. Wrappers are indicated in the refactoring menu with a Visual Studio icon, as in the Rename and Reorder Parameters refactorings appearing in the refactoring menu below:

In this section you'll find descriptions for all refactorings shipping inside CodeRush Xpress, arranged in the following categories:

Changing Signatures
Conditionals
Declaration & Initialization
Expressions
Interfaces
Lambda Expressions & Anonymous Methods
Loops & Blocks
Properties & Fields
Moving/Extracting Methods
Resource Files & Strings
Types
Visibility

Consult the Visual Studio help after installing CodeRush Xpress for additional details and example code in both C# and Visual Basic demonstrating these refactorings in action.

Changing Signatures

Add Parameter

Adds a new parameter to a method declaration and updates all calls accordingly.

Create Overload

Creates an overloaded method similar to the one at the caret, with fewer parameters. Applying this refactoring leads to an interactive phase where you can select which parameters to exclude from the new overload. XML doc comments are updated appropriately. You can even create overloads of constructors, as shown in the screen shot below:

Decompose Parameter

Replaces a single parameter with one or more new parameters, each standing in for a property access on the original parameter. For example, consider the code below:

In the first constructor, only a single property of the parentGrid parameter, Children, is accessed inside the code (and aside from this property reference, parentGrid is never referenced or assigned to directly in the code). So we can replace this parameter with a parameter of the same type as the property referenced. The preview hint for Decompose Parameter shows the impact of this change:

After applying this refactoring, all calls to the method are updated. The final code looks like this:

Promote to Parameter

Removes all references to the local declaration or field from the method, replacing it with a parameter. Calling code is adjusted to pass in the promoted field or expression.

In C#, CodeRush Xpress simply adds a preview hint wrapper around the existing refactoring.

In Visual Basic the refactoring is available as well, however in this case CodeRush Xpress actually implements the refactoring instead of handing off to the language service:

Remove Unused Parameter

Removes an unused parameter from a method declaration and updates all calls accordingly.

In Visual Basic this refactoring is only available on parameters that are not referenced within the method:

In C# the Remove Unused Parameter refactoring is not available, however there is a wrapper for the built-in C# refactoring Remove Parameters, and that wrapper is available when the caret is on any parameter:

When you select the Remove Parameters, CodeRush Xpress calls the built-in C# refactoring, which allows you to select the parameters to remove:

Note: The image above is a dialog from Visual Studio and is not part of CodeRush Xpress.

Reorder Parameters

Reorders parameters in the current method, and then updates calling code to reflect the new order.

In C#, this refactoring hands control over to the existing C# implementation of Reorder Parameters:

Note: The image above is a dialog from Visual Studio and is not part of CodeRush Xpress.

In Visual Basic, the application of this refactoring leads to an interactive phase where parameters can be rearranged using the CodeRush Xpress in-source UI. A hint appears revealing available shortcuts in the interactive mode.

Safe Rename

Safely renames non-private methods and properties by creating a duplicate member to preserve the old signature, calling the renamed member from the old member. The old member is hidden from Intellisense and marked "Obsolete". References to the old member will generate compiler warnings directing developers to the new renamed member.

After applying this refactoring, CodeRush Xpress selects and links the method name for an easy rename.

Safe rename is useful if you want to change the signature of a public or protected method referenced by code outside of your solution (e.g., on a developer's machine in another part of the world making calls to your API). For example, after performing the Safe Rename on the code shown above, we can next apply Remove Parameter to the unused deprecatedData in the FindPlayers method, cleaning up its signature without breaking any code that calls the now-obsolete FindAllThePlayers method.

Conditionals

Combine Conditionals

Combines nested conditionals to into a binary expression performing a logical AND operation. For example, "if (e1) if (e2)" becomes "if (e1 && e2)". This refactoring is the opposite of Split Conditional. This refactoring can also combine two or more neighboring conditionals with identical bodies into a single conditional statement where each conditional expression is logically OR’d.

Here's an example where nested conditionals can be combined:

And here's an example where neighboring conditionals with identical bodies can be combined:

Combine conditionals will also remove any redundancy that might appear in the newly combined expression. For example, notice in the preview hint for the following how the reference to the hasQualified parameter appears only once:

Compress to Ternary Expression

Converts an if/else conditional with assignments in each branch into a ternary expression. This refactoring is the opposite of Expand Ternary Expression.

Expand Ternary Expression

Converts a ternary expression into an if/else block. This refactoring is the opposite of Compress to Ternary Expression.

Before:

column = cellPosition == CellPosition.Last ? _NumColumns - 1 : 1;

After:

if (cellPosition == CellPosition.Last)
    column = _NumColumns - 1;
else
    column = 1;

Flatten Conditional

Unindents all or a portion of the conditional statement. This refactoring applies one of the following refactorings: Replace Nested Conditional with Guard Clause, Remove Redundant Else, or Reverse Conditional followed by Remove Redundant Else. Flatten conditional can also recognize “if (E) return true; else return false;” and convert all of this to simply “return E;”.

Here's one example for Flatten Conditional, where an indented code block (the last one of a method) becomes unindented by reversing the conditional and exiting the method:

Here's another example preview hint for Flatten Conditional, where an else keyword and the corresponding braces are removed, unindenting the contents of the block:

Reverse Conditional

Inverts the logic in this conditional statement and swaps the If and Else blocks.

Split Conditional

Two behaviors:

Converts a conditional with a binary expression performing a logical AND operation into nested conditionals. For example, in C#, "if (e1 && e2)" becomes "if (e1) if (e2)".

Before:
   if (fileName != null && fileName != String.Empty)
     PlayInCell(fileName, column, row);

After:
   if (fileName != null)
     if (fileName != String.Empty)
       PlayInCell(fileName, column, row);

Converts a conditional with a binary expression performing a logical OR operation into neighboring conditionals.

Before:
   if (fileName == null || fileName == String.Empty)
     return;

After:
   if (fileName == null)
     return;
   if (fileName == String.Empty)
     return;

Declaration & Initialization

Convert to Initializer

Converts a default constructor call immediately followed by object initialization into an object initializer.

Decompose Initializer

Converts an object initializer to a default constructor call followed by object initialization. Available when the caret is on type reference in the constructor call.

Before:
MediaPlayerPro mediaPlayerPro = new MediaPlayerPro { NumColumns = 3, StartingFolder = @"C:\Images" };

After:

Note the variable name is linked up after decomposing the initializer, allowing for a quick rename if desired.

Make Explicit

Converts an implicitly-typed local variable to a variable with an explicit type.

Make Explicit (and Name Anonymous Type)

Converts an implicitly-typed local variable to a variable with an explicit type, creates a named type to represent the expression on the right, and replaces the anonymous type with a newly-declared type. Other anonymous types in this project having the same shape will also be replaced by the new type.

Make Implicit

Converts an explicitly-typed variable declaration to an implicit one.

Move Declaration Near Reference

Moves the declaration statement for a local variable near its first reference.

This refactoring is sometimes useful in preparing a block of code for Extract Method (if a selected block contains the variable declaration, the variable won't need to be passed in as a input parameter).

Move Initialization to Declaration

Combines a local variable's declaration with its first initialization.

Name Anonymous Type

Replaces the anonymous type with a newly-declared type.

Additionally, other anonymous types in this project having the same shape (matching property names of the same types) will be replaced by the new type. For example, watch what happens when you apply this refactoring the first anonymous type assigned to the variable superCar1 below:

Before:
var superCar1 = new { MaxSpeed = 250, Driver = "Speed" };
var superCar2 = new { MaxSpeed = 250, Driver = "Racer X" };

After:
var superCar1 = new SuperCar(250, "Speed");
var superCar2 = new SuperCar(250, "Racer X");

The anonymous type assigned to superCar2 is also replaced by the new type.

Remove Assignments to Parameter

Removes assignments to value parameters, declaring a new local at the first assignment.

Split Initialization from Declaration

Breaks an initialized declaration for a local variable into a declaration and a separate initialization statement.

Before:
string[] files = System.IO.Directory.GetFiles(_StartingFolder);

After:
string[] files;
files = System.IO.Directory.GetFiles(_StartingFolder);

Split Temporary Variable

Splits a local variable which has too many assignments, declaring a new local at the first new assignment following the first reference. In this example where the local variable "i" has multiple assignments and references, the preview hint shows a new variable named "splitI" will be introduced, and all subsequent references to "i" will be replaced with the new splitI variable.

Expressions

Inline Temp

Replaces all references to a local variable with its initial value.

Introduce Constant

Declares a new constant, initialized to the value of the string or number at the caret.

Introduce Constant (local)

Declares a new local constant, initialized to the value of the string or number at the caret.

Introduce Local

Creates a new local variable initialized to the selected expression. Replaces the selection with the new variable.

After applying this refactoring, the new local variable name is selected and linked up...

So it is easy to rename...

Introduce Local (replace all)

Creates a new local variable initialized with the selected expression. Replaces the expression everywhere it appears inside the code block with the new variable.

Simplify Expression

Resolves an expression to its simplest form. Simplify Expression will remove redundancy such as extra parentheses and sub-expressions that have no impact on the outcome of the evaluation. For example, consider the redundancy in the expression in the method below:

To simplify this, select the expression and press the CodeRush key (Ctrl+`). The preview hint shows how the expression will be simplified. Notice that we lose the redundant reference to the hasQualified parameter, and we also lose an extra pair or parens, resulting in a cleaner expression that is easier to read.

Interfaces

Extract Interface

Extracts an interface based on public members in a class.

Lambda Expressions & Anonymous Methods

Compress to Lambda Expression

This refactoring is only available in C#.

Converts an anonymous method to an equivalent lambda expression.

Expand Lambda Expression

This refactoring is only available in C#.

Converts a lambda expression to an equivalent anonymous method.

Inline Delegate

This refactoring is only available in C#.

Inlines the delegate, creating an anonymous method. If there are no other references to the delegate method, it is removed.

Name Anonymous Method

This refactoring is only available in C#.

Creates a new delegate method from an anonymous method which does not access any local variables from the parenting method body.

After applying this refactoring the method names will be linked up allowing you to easily rename the new method.

Loops & Blocks

Add Block Delimiters

This refactoring is only available in C#.

Embeds a child statement inside brace delimiters.

Before:
if (files == null)
    files = Directory.GetFiles(_StartingFolder);

After:
if (files == null)
{
    files = Directory.GetFiles(_StartingFolder);
}

Create With Statement

This refactoring is only available in Visual Basic.

Creates a Visual Basic With statement for the specified instance within the selection.

If more than one qualifying instance exists, a sub menu will allow you to select the instance to become the subject of the With statement.

Inline With Statement

This refactoring is only available in Visual Basic.

Inlines the object reference of a Visual Basic With statement into all dot-references.

Remove Block Delimiters

This refactoring is only available in C#.

Removes unnecessary brace delimiters in C#.

Before:
if (files == null)
{
    files = Directory.GetFiles(_StartingFolder);
}

After:
if (files == null)
    files = Directory.GetFiles(_StartingFolder);

Properties & Fields

Convert to Auto-implemented Property

This refactoring is only available in C#.

Removes the backing store and converts the active property to a C# auto-implemented property. Available when the caret is on the property name.

Convert to Auto-implemented Property (convert all)

This refactoring is only available in C#.

Converts all properties in the active C# type to auto-implemented properties, removing the associated backing store fields.

Create Backing Store

This refactoring is only available in C#.

Converts a C# auto-implemented property to a conventional property with a backing store.

Before:
public string StartingFolder { get; private set; }

After:
private string _StartingFolder;
public string StartingFolder
{
   get
   {
    return _StartingFolder;
   }
   private set
   {
    _StartingFolder = value;
   }
}

Encapsulate Field

Encapsulates a field into a read-write property and replaces all occurrences of this field with the newly declared property. In C# control is passed to the built-in refactoring that encapsulates fields. In Visual Basic CodeRush Xpress implements this refactoring.

Encapsulate Field (read only)

Encapsulates a field into a read-only property and replaces all read-references to this field with the newly declared property.

Method to Property

Creates a property from the current method.

Before:
public string GetStartingFolder()
{
    return _StartingFolder;
}

After:
public string StartingFolder
{
    get
    {
      return _StartingFolder;
    }
}

Property to Method(s)

For read-only properties:
    Converts the property into a function.
For write-only properties:
    Converts the property into a method (or Sub in Visual Basic).
For read/write properties:
    Converts the property into two methods, creating a new function for the getter, and a new method for the setter.

Moving/Extracting Methods

Extract Method

Creates a new method from the selected code block. The selection is replaced with appropriate calling code to invoke the newly-declared method.

In C# control is passed to the built-in refactoring that extracts methods. In Visual Basic CodeRush Xpress implements this refactoring.

Extract Method to Type

Creates a new method from the selected code block and moves it to the specified type, updating the selected code block appropriately. The selection is replaced with suitable calling code to invoke the newly-declared method through an instance of the target type. This refactoring is useful when you have a block of code that references several properties or methods on a variable of a type that is declared elsewhere in your solution.

After extracting the code block above, the new method looks like this:

And the calling site looks like this:

Extract Property

Creates a new property from the selected code block. The selection is replaced with appropriate code to reference the newly-declared property.

After extraction the property name is selected and linked up for an easy rename.

Replace Temp with Query

Replaces each reference to this local variable with a call to an extracted method, which returns the initial value assigned to this local.

Resource Files & Strings

Extract String to Resource

Extracts the string at the caret into a resource file.

After extracting the string, the resource identifier is selected and linked for an easy rename.

This refactoring is useful if you have text that needs to be translated into one or more target languages. Placing all text that needs translation into a resource file makes it possible to change and add foreign language support without changing the code.

Extract String to Resource (replace all)

Extracts all matching strings in the file to a resource file.

Extract XML Literal to Resource

This refactoring is only available in Visual Basic.

Extracts the active embedded XML literal to a resource file.

After the extraction the resource identifier is selected and linked up for an easy rename.

Use String.Format

Converts a composed string expression into a single String.Format call.

Notice in the preview hint how the formatting arguments passed to the ToString calls in the original expression (e.g., "listPrice.ToString("c")") are properly converted to the appropriate format strings (e.g., "{0:c}").

This refactoring is useful if you have concatenated display text such as this that needs to be translated into another language. Complete sentences are more effectively translated than sentence fragments, as they can be grammatically rearranged as is sometimes necessary with translation, without touching the code.

Use StringBuilder

Replaces the selected string concatenation operations with corresponding method calls on a local StringBuilder instance. For example, consider the following code:

To change these string concatenation operations to equivalent code that works uses a StringBuilder, just select the text to convert and press the CodeRush key (Ctrl+`).

The preview hint gives you an idea of the changes this refactoring will apply to the code. Old string concatenation operations ("+=") are updated.

Notice also the intelligent changes applied to the second line that had previously called String.Format. That call has been converted to an AppendFormat call.

Types

Move Type to File

Creates a new file with the same name as the type at the caret, adds the file to the project, and then moves the type to that file, along with any leading comments, attributes, and XML doc comments. This refactoring is available when the caret is on a type declaration and the file contains two or more types.

After applying this refactoring, the type is moved to a new file with a matching name, and added to the active project:

The new file is activated so you can work in that file if needed. As always, when a feature in CodeRush Xpress takes you away from where you started, you can get back to the original location by pressing Escape.

Visibility

Widen Scope

Moves a variable declaration up (out) in scope, increasing the area where it can be referenced within the method.

Widen Scope (promote constant)

Moves the local constant declaration out of the member and up to the type, replacing all matching values in the type with a reference to the constant.

Widen Scope (promote to field)

Converts a local variable to a field variable.

More Information

Documentation on all the features of CodeRush Xpress, including samples in both C# and Visual Basic, can be found in the Visual Studio help after installing. Just select the Help | Contents menu item:

The help also includes sample animations for C# and Visual Basic, so you can see the features in motion.

Performance and Memory Milestones in CodeRush and Refactor! Pro - Preview of 9.2

Mark Miller (DevExpress) — Wed, 17 Jun 2009 19:10:00 GMT

The IDE Tools team has been spending a great deal of time making CodeRush and Refactor! Pro run even faster and with less memory. With every release since 3.2.3, customers have noticed improvements in speed. And it's no different for CodeRush 9.2, expected later this quarter.

Performance

Our primary focus for performance in this release has been solution load times. Specifically, we want to reduce the time it takes to go from specifying a solution to open in Visual Studio to the ability to refactor anywhere that a solution (we call this "zero-to-refactor" time). Refactoring anywhere means CodeRush has a full understanding of all the code in the entire solution.

To give you an idea of what you can expect in CodeRush 9.2, we took some measurements of this zero-to-refactor time with three of our internal DevExpress solutions. Two of these solutions are among our largest: DX Controls (8000+ files, anyone? Holy crap!) and XAF. The third is a medium-sized project, XtraScheduler. The table below gives you an idea of their respective sizes using a variety of metrics:

	DX Controls	XAF	XtraScheduler
# of Projects	51	54	9
# of Files	8,056	1,980	660
# of Types	17,351	4,295	2,235
# of Members	209,384	32,250	22,215
Lines of Code	1,831,086	255,759	389,954
Source Size	84MB	16MB	18MB

How do your solutions compare to these?

Some details on the test machine:

Processor

Intel Core 2 Duo E6400, 2.13 GHz

Memory

2 GB

Hard disk drive

Seagate st3250824as, 7200 RPM

(8ms average seek time,

9ms average write time)

Operating system

32-bit Vista, SP1

And it's Windows Experience Index:

First Time Loads

When you first open a solution, CodeRush 9.2 parses it and caches important information using a background thread. The cache later improves the zero-to-refactor time for subsequent loads of the same solution.

The parse and cache-building times for first-time loads for each of the solutions in CodeRush 9.2 are about the same as the old parse times (and no cache building) for CodeRush 9.1:

Even though CodeRush 9.2 performs additional functionality on the first-time load (e.g., parsing the code and building the cache), the team has actually found ways to improve the parsing speed sufficiently so as to have an overall effect of marginally reducing the zero-to-refactor time.

By the way, if you are looking at that 200-second parse and cache-building time for the DX Controls project and on the verge of freaking out, you may find relief in the following:

That time is from zero (no solution open) to the ability to instantly initiate a refactoring anywhere (no build required).
This is all happening in a background thread. Visual Studio remains responsive during this time.
The DX Controls solution declares over seventeen thousand types and over two hundred thousand members. It's 84MB of source code and nearly two million lines of code long. This solution is significantly larger than most solutions out there.
This cache-construction stage only occurs once -- the first time you open a solution without a cache.
This zero-to-refactor performance for first-time solution loads is actually comparable if not significantly faster than the competition.

Subsequent Loads

For subsequent solution loads after the cache is built, the story is even better:

Notice that once the cache is built, subsequent times to load a solution and get from zero-to-refactoring for CodeRush 9.2 (middle row in red) approach those of Visual Studio's normal load time for the solution (front row in blue).

The bottom line is CodeRush 9.2 gets you to that point of total code understanding where you can refactor anywhere significantly faster than CodeRush 9.1. In some cases up to five times faster.

Memory Consumption

Remarkably, the memory story is even more compelling than the performance story.

The data below shows total Task Manager memory after loading one of these large solutions and reaching that point where we're able to refactor anywhere in the solution (all source code has been parsed). Measurements were taken with Visual Studio 2008 alone (no add-ins), and with CodeRush 9.1 and CodeRush 9.2.

By the way, if you're using a competing IDE productivity tool and wondering how much memory that other tool might be consuming, it's likely to be very close to the memory consumed by CodeRush 9.1 (see the back row in purple).

Notice the significant drops in memory consumption produced by CodeRush 9.2 (middle row in red) compared to the memory consumption of CodeRush 9.1 (or your other IDE productivity tool). The savings in memory is huge, especially considering the size of these projects and the fact that this memory also holds all the assemblies required simply to keep CodeRush (and Refactor! Pro) running.

The percentage numbers in white near the top of each bar show how much additional memory is required by CodeRush (to represent the entire solution as well as its referenced assemblies) as a percentage of that needed by Visual Studio alone (if you didn't have CodeRush installed).

Whereas CodeRush 9.1 (in purple) requires about double the memory Visual Studio needs, CodeRush 9.2 requires substantially less. We expect most customers with large solutions to see a reduction in memory consumption of at least 100MB. Customers with very large solutions (e.g., 2000 files and up) should see even greater savings.

Can I Try This Now?

Yes you can. Between now and the release of CodeRush 9.2, CodeRush customers can request a daily build of CodeRush 9.2 from support@devexpress.com.

Processor	Intel Core 2 Duo E6400, 2.13 GHz
Memory	2 GB
Hard disk drive	Seagate st3250824as, 7200 RPM (8ms average seek time, 9ms average write time)
Operating system	32-bit Vista, SP1