Mark Miller
  • Is there a Roslyn-based CodeRush in your Future?

    At this year’s //build/ conference, Microsoft announced the open-sourcing of Roslyn, their .NET compiler for the next version of Visual Studio. Roslyn supports code analysis and code generation for C# and VB.NET languages.

    CodeRush customers have enjoyed functionality similar to Roslyn, built-in and shipping since 2005. Although, unlike Roslyn, which currently supports only C# and VB, CodeRush also supports JS, HTML, XAML, CSS and other languages. That functional similarity between Roslyn and CodeRush is unlikely to be accidental. First, having first-class compiler, language analysis, and code generation available to Visual Studio extensions is a really good idea, and good ideas are bound to be validated and improved upon again and again. And second, Dustin Campbell, previously a lead developer for the CodeRush team, has moved on to Microsoft and has been a leading force on the Roslyn team since its inception.

    However, in some ways, Roslyn is better than CodeRush’s core engine. One of the things we really like is the snapshot feature, which allows several different plug-ins to safely work asynchronously with read-only images of the code taken at different points in time without blocking the UI thread. And while one of our competitors has openly worried that this will lead to excessive memory consumption, this seems extremely unlikely due to the Visual Studio team’s cleverly efficient design (where snapshots are only a little bigger than the memory required to hold the code changes that have occurred since the snapshot was taken) as well as likely real world scenarios where snapshots are never really needed for a long time, and only exist for as long as they are needed.

    The other thing we really like about Roslyn is that Microsoft has finally managed to find performance improvements that beat the same highly-optimized, high speed features we have in CodeRush, such as find all references (which serves as a foundation for many refactorings including Rename). Prior to Roslyn, CodeRush had the fastest .NET find all references (FAR) available, beating Visual Studio’s FAR time as well as all of our competitors year after year. And so we find Microsoft’s performance improvements to be impressive.

    Functional and Physical Overlap

    Since Visual Studio 2003, any Visual Studio add-in that offered refactoring features also came at a cost, in the form of less-than-ideal performance due to duplication of effort, as well as the additional memory required to hold similar information. Over the years, the CodeRush team made significant advances in the area of both performance and memory optimization. However, we always knew that no matter how hard we tried, there would always be a functionality overlap where CodeRush and Visual Studio were both doing similar work, as well as a physical overlap where CodeRush and Visual Studio were both holding similar structures in memory. And until Roslyn, this overlap was unavoidable.

    Integration Challenges

    While moving CodeRush to work more closely with Roslyn offers an interesting potential, it is fraught with challenges. For example, Roslyn only supports C# and VB, while CodeRush’s language-independent source code tree supports many more languages. There are changes required throughout the product. In some cases those changes are minor, and in other cases the changes are significant and may even impact third-party plug-ins.

    Currently CodeRush plug-ins enjoy the benefit of working with a language-independent source tree. Refactorings don’t need to know if they are working with C#, C++, VB, JavaScript, etc.; they simply work with all languages. So this extensibility model might have to change.

    CodeRush also has over 20,000 test cases, and integrating with Roslyn would likely impact those as well.

    The Decision

    We like what the Visual Studio team has done, and we see the Roslyn technology (and its expected derivatives supporting other languages) to be the foundational future of extensible IDE design. And so the CodeRush team is all-in.

    We have already started building a version of CodeRush dedicated to totally exploit everything Roslyn has to offer. CodeRush customers can expect noticeable speed improvements for a number of refactorings and core features, as well as see a dramatic reduction in memory usage (e.g. 200MB-400MB less memory consumed for most medium to large projects),

    Although this decision is ambitious, the team is taking steps to work as efficiently as possible. For example, we are prioritizing efforts to ensure the most important and the most sophisticated core features get attention first, and we are looking at ways to ensure that every one of our existing test cases remains untouched.

    As we get closer to widespread Roslyn adoption, we’ll keep you updated with our progress. By the way, Microsoft recently open-sourced the Roslyn project. To learn more, click here.

  • New in CodeRush 13.2: Unit Test Builder

    Here’s a new feature that will help you generate test cases as you’re stepping through code. You know the scenario – you’re debugging and find a problem caused by the data passed in or the state of the software. You might want to continue stepping through the code but you also want to add a test case for the method you’re in right now.

    CodeRush has a cool new feature to help out in this situation. The Unit Test Builder (UTB). Here’s how it works:

    1. You will need at least one test project referencing at least one test framework. Which framework you pick doesn’t matter. CodeRush supports them all, and the UTB supports projects with references to multiple test frameworks.
    2. Start your debugging session and get to someplace interesting. For example, here I have a call to a class that calculates prime numbers:


      As you can see from the Expression Explorer, we’re passing in 4 and the IsPrime method is returning true. Four is NOT a prime number, so this is clearly a bug. Let’s step into the IsPrime method…


      This is the method that is returning the incorrect value when the candidate parameter is four. Four is not a prime number, so it should return false instead of true. We can figure out why later, but for now we should add a test case, so we….
    3. Press Ctrl+Alt+Shift+T to generate a new test case for this method, with the data passed in matching our arguments. The Unit Test Builder will appear:

      Here you can see a list of tests that will be generated after the debugging session ends. Hovering over the method in the “Method Called” column produces a hint showing the values passed in:

    4. Let’s rename the test method. Let’s call it FourIsNotPrime.

    5. We can place this method inside a different class if we want, or we can use the existing test class, or we can create a new test fixture to hold our test method.

    6. Finally, we can add optional remarks that will appear inside an XML doc comment.


      Note that all of these steps with the UTB (4-6, above) are completely optional. You can continue to debug and add test methods without making any changes to the names of the test methods or where they will be placed.
    7. Continue to debug, and add more tests as needed.

    8. Finally, when you’re finished, stop the session or close the application you’re debugging just as you normally would. At this point all the tests we’ve added to the UTB will be generated.


      Double-click a test in the UTB to navigate to that test.
    9. Now you add the assertion code (CodeRush has templates for this – “at” yields Assert.IsTrue, and “af” gives you Assert.IsFalse, for example).

    The final code for our test fixture looks like this:

    public class CalculatorTests
      Calculator _Calc;
      public void Initialize()
        _Calc = new Calculator();
        _Calc.Owner = this;
      public void TestIsPrime5()
        int candidate = 5;
        bool result = _Calc.IsPrime(candidate);
      public void TestIsPrime10()
        int candidate = 10;
        bool result = _Calc.IsPrime(candidate);
      // These two methods were generated following the
      // steps shown above in this blog. Note that the
      // UTB is smart enough to realize that we need
      // an instance of Calculator and that this test 
      // fixture already had one. So we use that instance 
      // in the generated test methods. 
      /// <summary> 
      /// Four is not a prime number! 
      /// </summary> 
      public void FourIsNotPrime()
        int candidate = 4;
        bool result = _Calc.IsPrime(candidate);
      /// <summary> 
      /// Nine is not a prime number! 
      /// </summary> 
      public void NineIsNotPrime()
        int candidate = 9;
        bool result = _Calc.IsPrime(candidate);

    The UTB is pretty cool. Give it a try and let us know what you think.

  • Customer Request: Insert a Method’s Parameters into a Template Expansion

    The Question

    This conversation popped up on Twitter:


    The customer wants a list of parameters inserted into a CodeRush Template. CodeRush Templates are like Visual Studio code snippets on steroids.

    My first thought: “We might have this. Let me check.”


    I opened the Template Editor options page, right-clicked the template expansion area, chose “Insert StringProvider”, and entered “param” in the Filter textbox:


    Unfortunately, nothing. StringProviders are code-based helpers located in plug-ins that deliver strings of text. I close this dialog.

    CodeRush also has TextCommands, which simply execute code (any code you write) from a plug-in. Sometimes that code execution can actually insert text in the middle of a template expansion. In cases like this, a TextCommand behaves similarly to a StringProvider. So I right-clicked the template expansion area again, but this time I chose “Insert TextCommand”, and once again entering “param” into the Filter textbox:


    Unfortunately, not what we were hoping for.

    So nothing we are currently shipping outputs a list of the current method’s parameters as a string. But I know we can do this pretty easily by writing our own plug-in.

    My reply on Twitter goes out:


    I return to my work, prepping for the pending release, and then it occurs to me – we can do this without a plug-in. One of the TextCommands we do ship with CodeRush is ForEach. It iterates over structural elements in your code, calling a specified template for each element found, and also optionally calling specified templates before, between, and after each element in the list.

    With some clever template creation, we can get the customer exactly what they need.

    CodeRush’s ForEach TextCommand

    Next I bring up the CodeRush User Guide, and click the “Reference\Text Commands” node, then click the ForEach TextCommand so I can take a look at the syntax. The dynamically-generated help page (generated from the plug-in TextCommand itself) looks like this:


    The ForEach TextCommand takes two required parameters (iterationBounds and the template to expand each time an element is found), and three optional parameters (firstTemplate, betweenTemplate, and lastTemplate – all names of templates to expand).

    I want to create a simple comma-separated list of parameters. So I will only need to use betweenTemplate (to place a comma and a space between each parameter name found). Note that this template will only be called if there are two or more elements in the list.

    Making it Work

    Now things get fast and easy. Inside the template editor, I create a new template for testing, named “zzz”. This template’s expansion looks like this:

    «ForEach(Parameter in Method,#AddParameter#,,#Comma#)»

    Notes on this call:

    • Parameter in Method is the iterationBounds. That means we’re going to iterate through every parameter in the active method (the method containing the caret).
    • #AddParameter# is the name of a template I haven’t created yet. It’s going to simply insert the text of the parameter and nothing more.
    • We pass nothing in for the firstTemplate argument.
    • #Comma# is the name of a template I haven’t created yet. It’s going to simply insert a comma followed by a space.
    • As a convention, I use the hash tag symbols around templates that I call from other locations (e.g., #Comma# and #AddParameter# – but these templates could have any name you want).


    Next I create the #AddParameter# template. It looks like this:


    This references the “Get” StringProvider, which is responsible for managing a list of variables and their values during template expansion. The ForEach TextCommand defines two variables for use in Templates – itemName (the name of the item being iterated), and itemType (that particular item’s type).

    So this template is done – it’s just going to return back the name of the parameter.

    Finally, I need to create the #Comma# template. This one is simple – just a comma followed by a space. I click OK to drop the CodeRush Options dialog.


    I move the caret inside a method with some parameters and enter the name of my test template – “zzz”:


    I press the Space bar (you might press Tab if that’s your template expansion key).

    I see this:



    The last step is to rename our “zzz” template into something more meaningful (e.g., #ParameterList#). You can rename templates by pressing F2 when the template is selected inside the Template Editor options page.

    Now whenever we need a parameter list in a template, we can right-click that template expansion, choose “Insert Alias…” (a way of calling templates from templates), and select our new #ParameterList# template to insert a list of parameters.

    Going Further

    Note that if we wanted to include the parameter type with each parameter, we could do that easily by modifying the #AddParameter# template to something like this:

    «?Get(itemType)» «?Get(itemName)»

    Then our template expansion might give us something like this:



    Learning More about TextCommands

    Here’s a video webinar Rory Becker and I recorded a while back, that introduces TextCommands and also goes into several examples of what you can do with the ForEach TextCommand:


  • CodeRush Shortcut Keys

    An updated CodeRush shortcut cheat sheet (in pdf format) is available, including new default shortcuts for debugging:

    CodeRushShortcuts1   CodeRushShortcuts2

    If you need the original source (for example, you want to modify shortcuts and print out your new version) in PowerPoint format, you can get that here.

  • Getting Started with CodeRush webinar

    On Tuesday, 1 October 2013 Paul Usher and I will walk you through quickly setting up and enjoying the benefits of CodeRush. We’ll start with a fresh install with default settings, and show how to customize the environment. We’ll also provide an introduction to some of the more powerful features of the product, including templates and code providers for high speed coding, refactoring, duplicate code consolidation, and the visual debugging features.

    Register for the webinar here.

  • CodeRush 13.1 - Enhancements to the Visual Studio Debugging Experience

    With the release of CodeRush 13.1, we have made several significant enhancements to improve the Visual Studio debugging experience, shedding more light on some of the more challenging-to-discern aspects of debugging.

    XAML Bindings in Silverlight 5

    Now when stepping through Silverlight 5 XAML binding code you’ll see previews of the binding properties. Gone is the need to bring up the Locals window, open the BindingState object, and then find and open the FinalSource property. Now the information you need is right where you’re looking – in the code.

    DV in SL5 
    Instantly see binding properties without looking away from the code, reaching for the mouse, or pressing excessive keystrokes.

    Improved Support for Exceptions and the Call Stack

    To make finding bugs even easier we’ve added the Call Stack and Exceptions (CS&E) tool window. While at first it may appear to be simply an easier way to read call stacks, like CodeRush itself, it’s more than a pretty face. It is especially handy when debugging asynchronous code.

    To show how useful it is, first let’s look at the typical Visual Studio asynchronous code debugging experience. We’ll measure the impact on usability along the way – if this gets too crazy for you, you can jump ahead to the “Now let’s try it with CodeRush…” section below.

    Async Debugging Experience in Visual Studio (without CodeRush)

    First the exception is thrown. Visual Studio stops execution here:


    VS Usability Impact so far: 1 target area visually scanned, 3 seconds invested

    Hmm. That’s not very helpful. Of course, Visual Studio also presents this dialog:


    Where’s the useful information? We have no indication of what code caused the problem.

    VS Usability Impact so far: 2 target areas visually scanned, 7 seconds invested

    Next you look at the call stack. It looks like this:


    Also, not useful.

    VS Usability Impact so far: 3 target areas visually scanned, 11 seconds invested. We’re going nowhere fast.

    OK, let’s go back to that exception helper window. Let’s click the “View Detail…” link.


    VS Usability Impact so far: 1 click, 3 target areas visually scanned, 12 seconds invested

    Here comes the View Detail dialog. It looks like this:


    No useful information yet. Good thing our hand is on the mouse. Move it up to the triangle and click it.

    VS Usability Impact so far: 2 clicks, 4 target areas visually scanned, 14 seconds invested

    Now we see this:


    Scanning this data, your eyes may have noticed the InnerException. What’s that all about? Let’s open it up. Click the triangle to the left of the InnerException node.

    VS Usability Impact so far: 3 clicks, 5 target areas visually scanned, 17 seconds invested

    You probably have to resize and scroll to see this data.

    VS Usability Impact so far: 4 clicks, 1 scroll, 5 target areas visually scanned, 20 seconds invested

    The contents of that InnerException node look like this:


    OK, so it feels like we’re getting closer. After visually scanning the InnerException child nodes, we can see three important pieces of information:


    The InnerException of this InnerException is null (which means we’re near the root of the problem). The Message tells us a parameter called “address” is null, and we have a stack trace that may finally be useful.

    VS Usability Impact so far: 4 clicks, 1 scroll, 6 target areas visually scanned, 26 seconds invested, and it seems we’re almost there.

    Let’s open up that stack trace.  First, click anywhere on that StackTrace line in the dialog. Then click on the drop down button to the right. If your Visual Studio is like mine, you’ll see something like this:


    Lovely. As an exercise in futility, try to read that wrapped call stack to figure out where your problem is. There is actually more to the call stack than you see in this drop down, unfortunately there’s no scroll bar to tip you off to that fact.

    After more clicking, scrolling, and reading (both above and below the visible parts of the call stack above), we might infer that our problem is at the topmost position of the call stack that references our application code:

    WindowsFormsApplication1.MailSenderAsync.<SendEmail> in MailSenderAsync.cs (line 27)

    VS Usability Impact so far: 7 clicks, 2 scrolls, 9 target areas visually scanned, 33 seconds invested, and it seems we’re farther away than we thought.

    So now we look at the code. Since there's no navigation support built in, we need to close this stack of windows.

    VS Usability Impact so far: 10 clicks, 2 scrolls, 9 target areas visually scanned, 36 seconds invested.

    Next we need to get to line 27 of MailSenderAsync.cs and take a look:

    VS Usability Impact so far: 11 clicks, 2 scrolls, 5 keystrokes, 9 target areas visually scanned, 41 seconds invested.


    Let’s press Ctrl+Shift+Space to see the parameter tool tip for the MailAddress constructor.


    Excellent! We’ve found the parameter named “address”. Getting closer.

    VS Usability Impact so far: 12 clicks, 2 scrolls, 8 keystrokes, 9 target areas visually scanned, 44 seconds invested.

    OK, so the “sender” parameter must be null. But how did we get here? How do we fix this? Unfortunately, after almost a full minute of clicking, scanning, and reading, we’ve only scratched the surface of understanding the problem. Typically the next step is to set a conditional breakpoint to stop when sender is null so we can investigate the call stack in more detail.

    From the Usability Count we’ve been maintaining it seems we’re investing a lot of development time going nowhere. We might need to set a breakpoint and try this again, or scan the call stack from the inner exception again to find out how we got here and find out how sender is getting a null value. Even a guru developer may be several seconds, if not minutes away from discovering the answer.

    Let’s compare this experience with Visual Studio on some serious family-friendly steroids, err CodeRush, plus our new CS&E window.



    Now let’s try it with CodeRush…


    By the way, if you already have the latest version of CodeRush installed, we recommend starting a new debug session (create new project and run it) right now and then open and dock the CS&E window at your favorite place in the editor while VS is in debug mode. This one-time step will get Visual Studio to remember this position and make sure the CS&E window is there for you in future debug sessions.

    I’ll wait while you do that.

    DevExpress | (CodeRush) | Tool Windows | Call Stacks and Exceptions. Smile

    OK, ready? Here’s how easy it is to find the bug with CodeRush:

    Starting with the same code and the same place as the previous example, click this link:


    CR Usability Impact so far: 1 click, 1.5 seconds invested.

    The CS&E window immediately looks like this:


    We’re debugging Async, so we know this outer call stack isn’t interesting. Instead we click the “Show inner exception” link above the stack.

    CR Usability Impact so far: 2 clicks, 3 seconds invested.

    Now we see this:


    Do you see that? The CS&E window is ACTUALLY HIGHLIGHTING the line of code contributing to our “sender equals null” problem. No need to visually scan the call stack. Just click the “MailSenderAsync.cs line 21” link, and we’re immediately inside this code:


    Are you kidding me? The Sender field variable, the parameter to the SendMail overload is ACTUALLY SELECTED. It’s actually selected, kids, drawing your eyes right onto the source of the problem, explaining how the sender parameter became null – the Sender field variable, passed into the method from line 21, was null. Now we’re much closer to understanding the problem. Nice.

    CR Usability Impact so far: 3 clicks, 5 seconds invested.

    When you’re debugging asynchronous code, the difference is huge. Here are the usability totals for this example:

      Visual Studio (alone) VS + CodeRush
    Clicks 12+ 3
    Scrolls 2+ 0
    Keystrokes 8+ 0
    Areas Visually Scanned 9+ 0
    Time invested 44+ seconds 5 seconds

    This is good stuff. CodeRush helps you stay focused on the code instead of wasting time struggling with suboptimal UI.

    Important notes about the CS&E window:

    • Make sure you have the “Automatically paste exception or call stack from clipboard” button in the down state to get this seamless ease of use.
    • You can copy call stacks and exception data from any location (including Visual Studio’s Call Stack window).

    This last point means you can send a call stack to a team member and they can copy it to the clipboard and see it inside the CS&E window, and they can use it to explore the same version of the code, EVEN IF THEY ARE NOT DEBUGGING. Impressive.

    Dead Path De-emphasis

    CodeRush de-emphasizes code on dead paths (e.g., outside the current execution path). Conditional blocks that won’t be executed on the current pass are grayed out, so as you’re stepping through code it’s even easier to focus on the code that will be executed.

    Code along the dead path (e.g., inside the conditional block) is grayed-out. We won’t be stepping into that block in this pass.

    Recursive Method Depth Counter

    CodeRush now displays a counter indicating the depth of recursive method calls. The counter appears when a method is called from itself at least one time.

    The Recursive Method Depth counter shows how deep you are into that method’s recursive call stack.

    The recursive call indicator reveals how many times the method appears on the call stack, so “2” is shown on the first recursive call.

    New Actions, New Options, and Other Debug Visualizer Improvements

    The following actions and default shortcuts are now available:

    • Toggle Expression Values - Ctrl+Shift+Alt+F10
    • Focus Next Expression - Tab
    • Focus Previous Expression - Shift+Tab
    • ToggleDebugVisualizer - Ctrl+Alt+D

    We have added a “Show historical values” option to the “Editor | Debug | Visualizer” options page. It specifies whether to show values only for the current code line or for all code lines within the current method. I prefer seeing a full history, however you may prefer a more compact display as you work.

    In Visual Basic, CodeRush now shows icons indicating whether the current Boolean expression is true or false for “case” statements.

    The Debug Visualizer is smarter and able to automatically preview more expression types than before.

    CodeRush smoothly adjusts line height when showing or hiding debug visualizer visual elements (expression values or Expression Explorer). This results in a smoother debugging experience and keeps your eyes on the important data.

  • New XAML features in CodeRush 13.1 for Visual Studio

    CodeRush 13.1 includes a number of new features to make working with XAML easier.

    Navigation Support

    The Declaration navigation provider is available in XAML code now. You can use it to navigate to:

    1. Control declarations
    2. Types
    3. Properties
    4. Resource keys
    5. Named controls
    6. xmlns aliases


    Code Completion

    With CodeRush 13.1 installed, Visual Studio’s XAML Intellisense is smarter and more capable. CodeRush suggestions are integrated with the Intellisense window, and include:

    • Available continuations for Binding path expressions and TemplateBinding arguments
    • Binding.ElementName, Setter.TargetName, and Trigger.SourceName values
    • Resource key completions for StaticResource and DynamicResource markup extensions.


    New Code Cleanup Rules for XAML

    The following XAML specific code cleanup rules are new for 13.1:
    Remove All Comments – removes all XAML comments.
    Remove Default Values – removes control attributes initialized to default values.

    Code Providers

    Declare XAML Namespace Reference

    This CodeProvider declares a new XAML namespace reference for the active qualifier.


    If the type resolves to multiple locations, a submenu will appear allowing you to select the namespace to declare.


    Declare All XAML Namespace References

    This CodeProvider declares multiple namespace references for every qualified control that can resolve to a single declaration. This refactoring can be useful after pasting XAML fragments from another source.


    Seven New Grid CodeProviders

    CodeRush 13.1 includes seven new Grid CodeProviders, which makes it much easier to work with controls inside XAML Grids.

    Insert Columns/Rows

    These CodeProviders insert the specified number of columns or rows at the specified location, shifting control position as needed. This CodeProvider can save a huge amount of time if you need to add a column or row to an existing grid. In the example below, we effortlessly add two rows to an already complex grid, shifting 50 control positions down automatically.


    Position Control

    This provider allows you to visually position a control inside the parent grid without reaching for the mouse or risking unintended changes (such as span and margins being set by the Visual Studio designer due to less-than-precise mouse operations).


    Delete Columns/Rows

    These CodeProviders remove the specified number of columns or rows at the specified location, shifting control position and span as needed. Controls contained entirely inside the deleted range will be removed unless the “(keep controls)” variation of this provider is applied.


    All grid manipulation operations are intelligently performed so undo is simple:


    Note: the first 13.1 release omitted the delete column/row providers. The subsequent minor update (and daily builds) include this feature.

    New Templates

    Setting Numeric Properties

    Now setting common numeric properties is fast and easy. Here are your shortcuts:











    Just follow these with a number (1-4 digits) and press the template expansion key. For example, the h149 template, when expanded inside a control’s tag, produces the following:


    Creating Controls

    CodeRush 13.1 includes a new set of dynamic code templates for creating common XAML layouts. New shortcuts for common controls:





























    The shortcuts above work anywhere a control is valid inside XAML. These templates will expand with a unique name. For example, pressing “b” followed by the Space or Tab key will produce the following:


    I should emphasize the name is unique, which is useful when you’re quickly prototyping or presenting to other developers.

    If you want to omit the name from the expansion, just follow the template with a comma (the comma is used throughout the CodeRush template library to produce shorter versions of many templates). So if you want a nameless border, just expand the “bd,” template.


    If you’re expanding one of these controls inside a grid, you can optionally specify the location using one of these modifiers:





    So to place a TextBlock inside row 1, column 2 of the parent grid, you can expand this template:


    This template will do the same thing:


    To omit the name, just follow the template with the comma.

    Modifying templates with grid position like we’ve seen above is optional. And as you might expect, with CodeRush, there is more than one way to get the job done…

    Positioning Controls inside a Grid

    The row and column modifiers seen above also work as stand-alone templates inside the main/start tag of a control. That means you can use any of these templates to set a control’s position within a grid:





    Also, don’t forget the Grid | Position Control provider shown above if you prefer a more visual approach.

    Creating Grids

    Need a grid that’s 3x3? Use the g3x3 template.

    Need a grid that’s 2x5? You guessed it – use the g2x5 template. Creating grids is easy. Just use this format:


    This animation shows how quickly you can set up a grid with the templates:



    Note: the initial 13.1 release of this template limits row and column counts to 9x9. Subsequent releases will increase this to 20x20.

    What’s that you say? You’re more of a visual person? Typing g2x5 is too much work for you? It gets easier. Here’s your new template:


    That’s right kids. You need a Grid of any size? Just hit the letter g followed by the template expansion key (typically Space or Tab, depending on your settings). Here’s what you’ll get:


    Exciting, isn’t it? On Monday I’ll show the cool new features we’ve added to the Debug Visualizer.

  • Here’s Your Game Changer: Debug Visualizer in CodeRush for Visual Studio

    One of the goals of team CodeRush is to release something revolutionary, something with the power to change the way developers work, at least once a year. CodeRush 11.2 was the first tool on any platform to offer duplicate code consolidation. This year CodeRush 12.2 comes out of the gate with another powerful game changer: the Debug Visualizer.

    The Debug Visualizer attempts to eliminate a number of productivity barriers inherent with today’s debugging experience. You may have noticed:

    1. The debugging experience can be slow
    2. Your hands reaching for the mouse to add a watch or inspect a value
    3. Your eyes moving back and forth between code and watched values

    Sometimes when stepping through code you encounter unexpected results. Unexpected results are frequently interesting because they can reveal details about the code that were previously unknown, and they are a smell indicating a logic error or bad data. Unfortunately the time from the moment you see the unexpected result to the moment you understand why is frequently measured in minutes, not seconds. Drilling down into a complex expression or reviewing historical data leading to a potential issue involves way too many mouse clicks and keyboard shortcuts, and may even require a restart in an attempt to catch the problem where it happens. Unraveling complexity is often tedious and may require intense focus.

    The Debug Visualizer is here to dramatically reduce the time between unexpected data and complete understanding.

    Here’s how it works.

    Historic Visual Record

    As you step into a method the Debug Visualizer immediately gets to work, revealing values for any arguments passed into the method.

    Figure 1: The Debug Visualizer acting like a Locals window, but without the messy window.

    Those local values you see just below the arguments persist as you step through this method, serving as a sort of historical document on the original values on entry or assignment, which may be useful if those later change inside the method.

    See Changes Right Where They Occur

    When values change as you step through the code, you’ll see those changes immediately. For example, in the screenshot below we can see the value of surfaceAreaOfCylinder is 0.0.

    Figure 2. An assignment statement before execution.

    Stepping over this line of code updates the local variable’s value, shown in red on the left:

    Figure 3. Now we can easily see which line of code changed a variable.

    Showing Function Results

    One debugging task that takes far too many steps and too much time is determining the value of a function that returns a calculation. There seems to be no easy way to get to this important information quickly.

    Fortunately the Debug Visualizer makes this pain a thing of the past. Now when you step up to a return statement, you can see the value returned before you leave the function:

    Figure 4: Easily see calculated values that functions return.


    Revealing the Future

    In addition to documenting the past, the Debug Visualizer can also reveal the future. Step through the code and you’ll see the values for expressions on the active line before they are executed. For example, in the code below, the Math.Sqrt() call has not been executed yet, however the future result, 42.0, can be seen right below the expression:

    Figure 5:  The future revealed, and the answer is… 42?

    If there is an unexpected value on the current line, many times it’s useful to know this before the line executes. It’s much easier to step into a method call or property getter before the line executes than after:

    Stepping into a Method Call or Property Getter:

    Before the Line Executes After the Line Executes
    OrangeDot Press F11 or Ctrl+Shift+F11

    OrangeDot Move the caret back to the problem line which might be far away if an exception occurred

      OrangeDot Press Ctrl+Shift+F10 to set the active line
      OrangeDot Wait for the line to become active
      OrangeDot Press F11 or Ctrl+Shift+F11

    The future previews are here to save all those extra steps and waiting.

    Values of expressions involving potential side-effects that may impact program behavior are not predicted; you’ll see a Refresh button instead. Click the button or press Ctrl+R to see the values.

    Expression Explorer

    So, what happens when you encounter an unexpected value while debugging? For this section, we’ll use a simple code example, however you might want to imagine this working on an expression with greater complexity.

    Figure 6: An unexpected value.

    With the caret anywhere on the active statement, press Alt+Down to bring up the Expression Explorer.

    Figure 7: Drilling into the expression.

    The Expression Explorer lets you drill into individual expression parts and see their corresponding values. In the screenshot above we can see the result of the call to Math.Sqrt() is 4.58 (we were expecting 5), and that the value of the expression passed into the Sqrt call is 21.0 (expecting 25).

    Once the Expression Explorer is up, you can move around and drill into expression parts with the arrow keys. For example, pressing the Down arrow (using the example code above) reveals the children of the active expression:

    Figure 8. Drilling further...  aSide * aSide == 9.0

    The Node Map to the right shows a hierarchical representation of the expression.  You can click and drag this window to reposition it if necessary.

    Figure 9. The Node Map reveals the active node (emphasized with high-contrast), parent nodes in purple, other nodes in blue, and hidden child nodes in gray.

    Notice the high-contrast active node on the left contains two hidden children (in gray). Sometimes you just want to take a peek at the child node values without actually changing the active expression. We can toggle child expression visibility by pressing the spacebar. Doing so in our example code produces the following:

    Figure 10. Spacebar toggles child expression visibility.

    In the screenshot above, we can see the 9.0 comes from 3.0 * 3.0.

    We can collapse all child expressions with the spacebar as well. Pressing spacebar again produces this:

    Figure 11. Collapsing the child expressions with the spacebar.

    The “9.0” value shown above for the “aSide * aSide” expression is expected, and the child expression values look good. Our problem must be elsewhere. Let’s move right.

    Figure 12. Continuing to explore…

    Expressions and their corresponding values are always left-aligned.

    Figure 13. Values are displayed below a horizontal line that matches the length of the corresponding expression.

    Let’s move down into the child expressions with the Down arrow.

    And to the right with the Right arrow:


    And now we can see our problem. This reference to “aSide” should have been a reference to “bSide”. Now we just need to fix the code. You can close the Expression Explorer by pressing Escape, or by clicking anywhere else in the editor. When the Expression Explorer closes, the code looks like this:

    Figure 16. The Expression Explorer has closed, and we can still see the last values explored.

    With Edit and Continue enabled we can fix the code. As soon as we make any change to the code the Debug Visualizer clears the historical data in the method we’re modifying.

    Figure 17. After editing.

    Of course, after editing, you can show the Expression Explorer again by pressing Alt+Down.

    Figure 18. Results are now as expected.

    Here’s the Expression Explorer in action:


    And here’s the Expression Explorer scaling up to a more complex expression:

    Figure 19. The Expression Explorer scales to handle complex code.

    Why is this Expression False (or True)?

    Sometimes when stepping through code with Boolean expressions an unexpected result appears. For example, you expected the expression to be true, but it is false. Or maybe you expected it to be false, but it is true. When this happens, the Expression Explorer can help you quickly understand why. For example, in this method we want to rent/hire a car. However the Debug Visualizer tells us this won’t happen:

    Figure 20. The Debug Visualizer optionally adorns Boolean expressions with “DebuggerVisualizerTrue” (true) or “DebuggerVisualizerFalse” (false) icons.

    So the question is “why is this expression false?” To find out, press Alt+Down to bring up the Expression Explorer:

    Figure 21. Conclusive Boolean expressions are highlighted (in green) in the code and the Node Map (as squares)

    Now we can immediately see the problem. It’s here, highlighted in green:

    Figure 22. Conclusive Boolean expressions determine the value of their parent expressions

    A parent Boolean expression might contain one or more conclusive Boolean child expressions. In this example there is only one. Let’s navigate into it to get more detail. Press the Right arrow to move right and select the conclusive Boolean expression:

    Figure 23. The conclusive Boolean expression, shown as a square in the Node Map, is selected.

    And now press the Down arrow (or spacebar) to see the children of this expression:

    Figure 24. And now we see why we can’t rent/hire the car.

    Highlighting conclusive expressions is useful for understanding why Boolean expressions are true or false.

    Evaluating Expressions with Side Effects

    Sometimes an expression might contain a method call or property getter access with potential side-effects. If CodeRush is unable to verify that the call is free of side-effects, the Debug Visualizer will display a Refresh button. As long as the line of code is active you can click this button (or Press Ctrl+R) to call into the method and get the result.

    Figure 25. Calls with potential side-effects (e.g., the call to “Exists()”) are highlighted.

    Note that even though an expression preview may be marked with a Refresh button, it may still be possible to drill down into its children to see their values without refreshing. For example, in the screenshot above, the Exists call prevents evaluation of the parent expression, however you can still see an evaluation of the “drive + path” expression.

    The Debug Visualizer is Here Now

    So there’s your game-changer for 2012, kids. Faster expression evaluation, historical record of changes, future reveal, function return preview, expression drill down, conclusive Boolean highlighting and important data always right where you need it – right in the source code. It works in C# and Visual Basic and is available right now in CodeRush 12.2 for Visual Studio. JavaScript support is expected in the next minor update. Give it a try and let us know what you think.



    A file lock issue experienced by some developers has been fixed since the 12.2 release. You can get the update here.

  • Consolidating Duplicate Code in Visual Studio – Easy with CodeRush

    On Twitter last week a developer mentioned a competing developer tool, inferring its clone detection and consolidation abilities were similar to what we were already shipping with CodeRush. Skeptical (I had looked into this tool once before months ago), I decided to dig deeper and found a video showing how to consolidate code with the tool. I watched a developer show step-by-step how to manually consolidate duplicate code found by the tool. Steps included determining the differences between the blocks of code and then manually removing them in each of the duplicated methods, then extracting one of the methods, then copying a method call and pasting it over each of the other duplicate methods. The entire process took nine minutes and 43 seconds. Wow.

    In the video the developer only worked with two duplicates, and those duplicates were both located in the same class; you could see the proposed solution would become incredibly difficult and error-prone to perform manually for duplicates in larger numbers or spread across classes.

    I consider the video a demonstration of how our ancestors used to consolidate code, back in the old days when dinosaurs roamed the earth.

    Here’s how you do it today with CodeRush:

    1. Open the project inside Visual Studio. The screenshots in this post are using the same source code sample I saw in the demo.
    2. CodeRush lists duplicates on the Duplicate Code tool window. Here are the duplicates CodeRush has found (on an extremely granular setting – you can adjust settings in Options):

      In the screenshot above I’ve circled the important differences.
    3. Double-click one of the duplicates. This takes you to the code and brings up the Consolidate Duplicate Code UI.

      The preview hint shows you the duplication will be turned into a single method inside the class UINameHelper.

    4. Select “to the current class”. The Target Picker (with a handy preview) lets you decide where to insert the new method:

    5. The Up/Down arrows change the target location.  I press Enter to accept the position and generate the consolidated method. Here it is:

    6. Let’s rename it to “BuildUINameFrom”. CodeRush updates the calling methods automatically:

    7. Then I rename the parameters in the consolidated method:


    And I’m done.

    Elapsed time: About two minutes (which includes two full runs of all the test cases). Kids, let me tell you why it’s important to work in the future rather than the past: Because spending ten minutes making high-risk manual changes is senseless when you can do it safely in seconds with CodeRush.

    Here’s the video showing how fast it is:

    Note we start the video from an empty Visual Studio (no solution loaded). As we load the solution watch how quickly the Duplicate Code window fills up. You can also see the Test Runner collect unit tests and populate itself in seconds as well. Nothing is faster than CodeRush.

    CodeRush is still the only tool that can consolidate your duplicate code automatically across classes and projects. For more information on CodeRush, click here.

  • Duplicate Detection and Consolidation in CodeRush for Visual Studio

    CodeRush 11.2 introduces a new feature we’re very excited about. It’s called Duplicate Detection and Consolidation (DDC) and it’s revolutionary.


    Duplicate code, sometimes referred to as clones, is a cluster of code blocks that are functionally equivalent (or nearly equivalent) spanning across two or more locations within a solution. Duplicate code is expensive to maintain because:

    1. Multiplied bugs. A bug in one clone means there’s a bug in all the copies. This can lead to a continued, repeated release of previously-fixed bugs as each copy of the bug is individually discovered by a customer and then fixed by the team.
    2. Flexibility barriers. If the copied code needs to be more flexible, changes need to be made across all the copies or ideally, the copies need to be consolidated first. Unfortunately consolidation is a high-risk, error-prone, time-consuming activity.
    3. Increased ramp-up time. Copy the code and new developers trying to get up to speed will have twice as much code to read and understand. If discovered, duplicated code tends to be harder to understand than normal code because the reader must not only understand functionality, but also understand the reason behind the duplication.

    Reaching into the Future

    Because duplicate code is such an expensive problem, for years tools have been developed to detect duplicate code, each achieving various degrees of success. So you might wonder, after so many years of development, what makes CodeRush’s DDC so revolutionary?

    1. Speed. CodeRush has the fastest duplicate code detection available for .NET. It’s 17 times faster than the duplicate code detection currently available in the Visual Studio 11 preview.
    2. Integration. DD runs in a background thread while you work in Visual Studio. Duplicate code is highlighted on screen so you know exactly what you’re working with before you change the code.
    3. Functional Equivalence. The CodeRush duplication detection engine is built to understand functionally equivalent code. In 11.2, we take baby steps in this direction. However, by 12.1 we expect to really be blowing minds in this area, matching structurally distinct yet functionally equivalent blocks of code.
    4. Consolidation. CodeRush is the first and only tool on this planet to offer the ability to immediately consolidate duplication into a single block of code, directly from the IDE. Not only is CodeRush first, but Team CodeRush has delivered an impressive solution.

    The Complexity of Consolidation

    To give you an idea of just how impressive duplicate consolidation is, let’s take a look at what needs to happen to consolidate:

    1. You need to understand not only the similarities, but also the differences among the code blocks. Differences can be parameterized.
    2. If the duplicate blocks of code are functionally equivalent but structurally distinct, then a decision needs to be made - upon which of the duplicate blocks should we base the consolidation?
    3. You need to offer a variety of consolidation solutions so the developer can pick the one that fits best. For example, you could consolidate to a new method in a class, create a new ancestor class, or create a new helper class.
    4. You need to understand and respect project boundaries. In many cases duplication between projects survives beyond initial discovery because consolidating is time consuming and may require the creation of a new project.  If a new project is created, the appropriate references need to be added. Regardless of whether we’re creating a new project or moving code from one existing project to another, we need to verify that we can do this without creating any circular references.
    5. Types need to be correctly resolved. You might have two classes with the same name declared in different namespaces in your solution. The consolidated code must have the correct namespace imports to ensure that all the types are correctly resolved.

    As a result, the steps to consolidate by hand are many, complex, error-prone, and high-risk. Only the best developers are brave enough to venture forth in this domain, and if they do, they are best advised to bring a paired programmer along for the ride.

    Enter CodeRush 11.2

    This changes everything. From this day forward, the quality of code is going up. Let’s take a simple example. I have a class named Mortal, which looks like this:

    public class Mortal
      protected List<Mortal> friends = new List<Mortal>();
    public string Name { get; set; }

    And a descendant named Human, which has a FindHuman method:

    public class Human : Mortal
    public Mortal FindHuman(string name)
    Mortal mortal = null;
        foreach (Mortal friend in friends)
    if (String.Compare(friend.Name, name, false) == 0)
    Console.WriteLine("Found a Human: " + friend.Name);
            mortal = friend;
    return mortal;

    So far so good. But now, let’s do something incredibly dangerous. We’re going to make a copy of this Human class and perform a search and replace, “Human” for “Martian”…

    public class Martian : Mortal
      public Mortal FindMartian(string name)
        Mortal mortal = null;
        foreach (Mortal friend in friends)
          if (String.Compare(friend.Name, name, false) == 0)
            Console.WriteLine("Found a Martian: " + friend.Name);
            mortal = friend;
        return mortal;

    But let’s continue to change the code. Let’s introduce a few local variables, rename “mortal” to “myFavoriteMartian”, remove the unnecessary curly braces around the if-block, and change case-sensitivity of the String.Compare call so it ignores case (as one might expect with Martian names)…

    public class Martian : Mortal
      public Mortal FindMartian(string name)
        Mortal myFavoriteMartian = null;
        bool ignoreCase = true;
    string msg = "Found a Martian: ";
    foreach (Mortal friend in friends)
          if (String.Compare(friend.Name, name, ignoreCase) == 0)
            Console.WriteLine(msg + friend.Name);
            myFavoriteMartian = friend;
        return myFavoriteMartian;

    And now we have some code that is functionally equivalent, but structurally distinct. Can CodeRush find this? It can, providing we drop the Analysis Level down to 2, so the detection engine can see this smaller code block (the default level is set to 3, which is a slightly larger block):


    Here’s what the code looks like inside Visual Studio:


    On the left of the gutter in each view, you see a thin purple vertical bar. This means duplicate code exists elsewhere. Also, in the bottom right, the “!!” icon signals CodeRush has detected duplicates inside the solution. If you hover over the icon in the bottom right, a hint appears to explain the status.


    You can click the icon to see a summary of all duplicate clusters found inside the new Duplicate Code tool window. In this case, our simple example, only one cluster is found:


    On the left is a list of all clusters found, sorted by redundancy (the total amount of redundant code that could be removed if consolidated). Note that because we are sorting by redundancy, it’s possible for a very small block of code (duplicated many times) to appear above a very large duplicate block of code (that only appears twice).

    On the right is a preview of the duplicate code. You can double-click any duplicate code preview to be taken directly to that location. When you do this, CodeRush immediately presents the consolidation hint, which looks like this:


    Notice the mouse is positioned right over the “Next duplicate block” button, in case you want to navigate and compare the blocks. This might be useful when it’s time to consolidate. The block you consolidate from determines the structure of the consolidated block. So let’s consolidate from the FindMartian method. Click the “Next duplicate block” button, then move the mouse over the “to the base class” consolidation option. You’ll see a preview hint that looks like this:


    Notice the parameters to FindMartianExtracted – CodeRush takes the code that differs between the blocks and turns them into parameters. Press Enter to apply the consolidation. The target picker will appear letting you select the location of the consolidated method.


    The target picker shows the block of code that will be inserted. It’s based upon the structure of the method where we initiated the consolidation (FindMartian). Let’s press Escape to cancel and back out of this, and then see what happens when we initiate consolidation from the other duplicate…


    Now consolidate to the base class Mortal. We’ll see the target picker. Notice how the FindHumanExtracted consolidated code in the preview below differs from the FindMartianExtracted consolidated code in the preview shown two screen shots above.


     Just use the up/down arrow buttons to select a location and press Enter to accept it. Now we’re left with a small task of coming up with good names for the consolidated method and its parameters.


    And the calling code is simplified:


    And that’s it (for a simple consolidation example)!

    An Even Bigger Example

    But what happens when the project is much bigger? The good news is, that the detection scales well for large solutions, taking only seconds (at most a few minutes) to scan thousands of files for duplicates at the default settings (Analysis Level set to 3). Let’s take a look at DDC with the source to Umbraco.

    Here’s cluster #4 selected. The Lowest and Highest methods inside the ExsltMath class:


    Nearly identical blocks of code. However note the real difference is in the operator used to compare t against min (and max). On the left you have “t < min”, and on the right you have “t > max”. Can CodeRush consolidate this duplicate? It can. Here’s the preview hint:


    And after consolidation (and renaming the method, the “min” local, and the “func” parameter), I get this:


    And now the quality of the code is much higher than it was before.

    Remember, CodeRush has the fastest duplicate code detection available for .NET. It works in the background and shows when you’re working inside a method that is cloned. Consolidation is based on the structure of the method you start from. While CodeRush can consolidate many kinds of duplicate blocks, not all duplicate blocks can be consolidated automatically (trust me, this is an incredibly challenging problem to solve). But we’re working on making the consolidation engine even smarter and even more extensive as we approach the 12.1 release (and we expect to blow your mind again with that one).

    Do me a favor, kids: Tell every developer you know about CodeRush’s Duplicate Detection and Consolidation. DDC is truly revolutionary; help us spread the word.

1 2 3 4
6 7 8 9 10

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

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


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

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