Mark Miller
  • Slicing and Dicing Strings with CodeRush for Visual Studio

    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.

    SplitStringInto2

    This will split the string into two pieces.

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

    SelectLastExpression

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

    GetDaysRemaining

    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.

    UseStringFormat

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

    ExtractStringToResource

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

    DaysRemainingResource

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

    SelectSlashN

    Press the CodeRush/Refactor! key and select Split String

    ApplySplitStringIntoThree

    Applying the refactoring will leave you with this:

    SplitStringInto2Applied

    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.

    AfterEnvironmentNewLine

    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:

    IntroduceFormatItemPreviewHint

    Apply the Introduce Format Item refactoring to get this:

    AppliedIntroduceFormatItem

    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.

    PromoteToParameter

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

    PromoteToParameterAfterRename

    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:

    EmbedString

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

    ConvertToString

    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

    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:

     FirstShot

    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:

     TestStatus

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

    Derek Reynolds says it all with a single screen shot.

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

    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:

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

    Drawbacks:

    1. 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:

    1. Single source code base as we move forward.
    2. 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:

    1. Use System.Drawing and convert to WPF types when we need to paint with WPF.
    2. Use System.Windows and convert to GDI types when we need to paint with GDI.
    3. 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

    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

    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

    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

    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:

    RefacrtoringsAndCodeProviders 

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

    NewDXCorePlugInProject

    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.

    PluginProjectSettings

    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.

    SelectCodeProvider

    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.

     SwitchToEvents

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

    CreateHandlerForCheckAvailability

    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:

    ThrowNewNotImplementedException

    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:

    ImplementPropertyIsAvailable

    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.

    HandleApply

    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.

    NewElementBuilder

    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.

    DeclareLocalElementBuilder

    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.

    ClickFormatFieldName

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

    FormatFieldName

    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:

    TreeVariable

    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:

    TreeProperty

    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:

    TreeGetter 

    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:

    TreeSetter

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

    TreeSoFar 

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

    UndoImplementProperty

    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:

    ExtractMethodPreviewHint

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

    PreparePreview

    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:

    ImplementPropertyPreviewHint

    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:

    PreviewHintVB

    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

    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.

    ide-tools-startup-options

    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.

    ide-tools-manual-load

    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.

    ide-tools-load-progress

    DXCore Version Switcher

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

    ide-tools-version-switcher

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

    Download CodeRush Xpress - free from Dev Express!

    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:

    FeatureSummary

    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:

    VB     C#  

    More details on CodeRush Xpress functionality follow.

    NavigateFeatures

    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.

    CamelCaseRight

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

    CamelCaseLeft

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

    CollectingMarkers

    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

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

    TabToNextReference

    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.

    HighlightAllReferences

    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:

    Quick Navigation - Smart Filtering

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

    QuickFileNavigation

    SelectFeatures

    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.

    CamelCaseSelect

    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.

    DeclareFeatures

    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:

    UsingIntellisenseToGetReturnType

    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:

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

      TypeExpression 

      CSharpSmall If you're working in C#, there is no need to end the expression with a semi-colon.
    2. 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:

      DeclaredLocal 

    So the steps behind exploiting consume-first features are:

    1. 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).
    2. Place the caret on the part that doesn't exist.
    3. 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.
    4. 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:

    NewTypeExpression

    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:

    FieldDeclaration

    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.

    DeclareStartTime

    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:

     CreateMethodContract1

    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.

    CreateMethodContract2

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

    DuplicateLine1

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

    DuplicateLine2 

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

    RefactorFeatures   

    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.

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

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

      Wrappers

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

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

    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:

      DecomposeParameter0

    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:

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

      DecomposeParameter2

    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.

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

    PromoteToParameter 
    VBSmall 
    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:

    PromoteToParameterVB

    Remove Unused Parameter

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

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

    RemoveUnusedParamter

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

    RemoveParameters

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

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

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

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

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

    ReorderParametersVB 

    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.

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

      SafeRename1

    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:

      CombineConditionalsAnd

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

    CombineConditionals

    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:

      CombineConditionals2

    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.

    CompressToTernaryExpression

    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:

    FlattenConditional

    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:


    FlattenConditional2

     

    Reverse Conditional

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

    ReverseConditional

    Split Conditional

    Two behaviors:

    1. 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);

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

      ConvertToInitializer

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

       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.

      MakeExplicit

    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.

      MakeExplicitAndNameAnonymousType

    Make Implicit

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

      MakeImplicit

    Move Declaration Near Reference

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

      MoveDeclarationNearReference
    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.
      MoveInitializationToDeclaration

    Name Anonymous Type

    Replaces the anonymous type with a newly-declared type.

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

      RemoveAssignmentsToParameter

    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.

    SplitTemp 

    Expressions

    Inline Temp

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

      InlineTemp2

    Introduce Constant

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

    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.

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

      AfterIntroduceLocal
    So it is easy to rename...

      AfterIntroduceLocal2

    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.

      IntroduceLocalReplaceAll

    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:

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


     SimplifyExpression

    Interfaces

    Extract Interface

    Extracts an interface based on public members in a class.

    Lambda Expressions & Anonymous Methods

    Compress to Lambda Expression

    CSharpSmall This refactoring is only available in C#.

    Converts an anonymous method to an equivalent lambda expression.

      CompressToLambdaExpression

    Expand Lambda Expression

    CSharpSmall This refactoring is only available in C#.

    Converts a lambda expression to an equivalent anonymous method.

    Inline Delegate

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

      InlineDelegate

    Name Anonymous Method

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

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

    Loops & Blocks

    Add Block Delimiters

    CSharpSmall 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

    VBSmall This refactoring is only available in Visual Basic.

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

      CreateWithStatement

    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

    VBSmall This refactoring is only available in Visual Basic.

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

      InlineWithStatement

    Remove Block Delimiters

    CSharpSmall 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

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

      ConvertToAutoImplementedProperty

    Convert to Auto-implemented Property (convert all)

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

    ConvertToAutoImplementedPropertyConvertAll

    Create Backing Store

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

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

    ExtractMethod

    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.

      ExtractMethodToType

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

      ExtractMethodToType1

    And the calling site looks like this:

             ExtractMethodToType2 

    Extract Property

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

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

      ExtractProperty2

    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.

      ReplaceTempWithQuery

    Resource Files & Strings

     

    Extract String to Resource

    Extracts the string at the caret into a resource file.

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

      ExtractStringToResource2

    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

    VBSmall This refactoring is only available in Visual Basic.

    Extracts the active embedded XML literal to a resource file.

      ExtractXMLLiteralToResource 

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

      ExtractXMLLiteralToResource2 

    Use String.Format

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

    UseStringFormat

    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:

                 UseStringBuilder0 
    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+`).

    UseStringBuilder1

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

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

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

      MoveTypeToFile2

    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.

    WidenScope

    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.

      WidenScopePromoteToField

    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:

    HelpContents

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

    HelpAnimations

    Download CodeRush Xpress - free from Dev Express!

3 4 5 6 7
8
9 10 11 12
LIVE CHAT

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 info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

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