Peter Ritchie's MVP Blog : DevCenterPost

Becoming a Visual Studio Jedi Part 1

PeterRitchie — Tue, 02 Sep 2008 18:49:00 GMT

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi

In much the same grain as James' Resharper Jedi posts, I'm beginning a series of posts on becoming a Visual Studio Jedi. It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible. I think it's useful for all users; but especially useful for those who are in situations where they can't install refactoring tools like Refactor Pro! or Resharper.

First, familiarize yourself with Sara's Visual Studio Tips blog; then subscribe to her blog.

I'll attempt to provide detail at a less granular level than Sara's blog (i.e. using a series of commands to perform a specific task); but I may overlap here and there

Take advantage of Auto-Hide
Like Jimmy Bogard and Jeffery Palermo, I have my Visual Studio UI very lean. 99% of the time, I'm working in code. The Solution Explorer (SE), Properties, Output, etc are auto-hide panes. When I need to use them I hover the mouse over the tab to make them visible, do what I need to do with them, then get back to the code. The Code Editor is the only window that isn't auto-hide or floating.

Navigate find results via keyboard
Whenever anything is displayed in a find results window, you can iterate each item in the list via a keystroke. The default C# keyboard map had F8 and Shift+F8 as the shortcuts for next and previous.

For example:

Press Ctrl+Shift+F to bring up the Find in Files form.
Enter "TODO\:.*refactor" in the "Find what" text box.
Ensure Match case, Match whole word are unchecked.
Ensure Use is checked and has Regular expressions selected.
Press Alt+F to search.

A Find Results window is displayed that shows the results of the search.

F8 goes to the first result.
Pressing F8 again goes to the next.
Pressing Shift+F8 goes to the previous result.

F8 and Shift+F8 work for most lists like Find Results 1, Find Results 2, Error List, Output:Build, etc.

File name extensions when adding classes
Do you find your self selecting text in the file name when you use the Add Class wizard? Or, do you always type ".cs" at the end of your file name? You may be happy to know you don't have to do that. Simply invoke the Add Class wizard and type the name of the class. The wizard adds the missing .cs for you. For example:
Press Alt+P, C
Enter "MyNewClass"
Press Enter
A file MyNewClass.cs is added to your project and it contains class named "MyNewClass".

Consider a Custom toolbar

There's generally only handful of toolbar buttons that you might need, especially if you're a keyboard user like me. There's some things that simply don't have a default keyboard mapping. Another good reason for having a custom toolbar item with only the buttons you use is if you often change the size of your Visual Studio window. The default layout has two or more toolbars (depending on the edition and any add-ins you have installed). You can carefully position those toolbars so they may take up one or two lines; but when you then shrink the size of your window the get wrapped and they won't restore if you expand the size of your window. Having a single toolbar means this wrapping of toolbars can never happen.

Export Settings

Once you get your UI the way you want it, you can actually save the layout.

Click on Tools\Import and Export Settings.
Select Export selected environment settings.

This is really handy if you get into low-resource situations (like the application you're developing or its framework uses up too many GDI handles and Visual Studio can't allocate a handle to display a toolbar or a frame. When this happens Visual Studio actually turns off those GUI elements; when you close and restart those panes/frames are no longer displayed by default.)

Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Tue, 10 Jun 2008 19:26:00 GMT

Single Responsibility Principle (SRP) helps us write more cohesive types and methods. Cohesion is the relatedness of the members of a type to each other and the relatedness parts of a method's code to other parts.

Method cohesion
Often times a method is not very cohesive, meaning the code that it executes relates to more than one thing. This can often be seen with a method that contains a large switch statement. For any invocation of the method only one case statement may be executed; meaning that blocks of code within the method don't relate to all the other blocks. Switch statements are often an indication that the design should be changed to be more polymorphic or introduce a pattern like the Strategy or Template Method patterns. Likely a concept of the design is implicit instead of explicit (at least no more explicit than an enum). For example:

    public class Set {
        public enum Operation {
            Unknown,
            Union,
            Intersection,
            RelativeComplement,
            And,
            Conjunction = And
        }
 
        public static IList<int> PerformOperation(IList<int> one, IList<int> two, Operation operation) {
            List<int> result = new List<int>();
            switch (operation) {
                case Operation.Union:
                    result.AddRange(one);
                    result.AddRange(two);
                    break;
                case Operation.Intersection:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.RelativeComplement:
                    foreach (int x in one) {
                        if (!two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.And:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                default:
                    throw new ArgumentOutOfRangeException("operation");
            }
            return result;
        }
    }

This code works; but it's far from cohesive. There are many combinations of execution paths this method can take, and each path is unrelated to the other paths. For example, the Union case has no relation to any of the other cases. Methods like this are also hard to maintain and prone to errors. Obviously if another member were added to Operation PerformOperation would have to change--making PerformOperation tightly coupled to Operation--not very object oriented.

This can be made more object-oriented by through Dependency Inversion and the Strategy Pattern:

    public class Set2 {
        public abstract class Operation {
            public abstract IList<int> Execute(IList<int> left, IList<int> right);
        }
 
        public class UnionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                result.AddRange(left);
                result.AddRange(right);
                return result;
            }
        }
 
        public class IntersectionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class RelativeComplementOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (!right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class AndOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
        public static IList<int> PerformOperation(IList<int> left, IList<int> right, Operation operation) {
            return operation.Execute(left, right);
        }
    }

Now each operation is encapsulated, explicit, PerformOperation need not change as new strategies are added, and we've completely avoided the InvalidOperationException.

Fundamentals of OOD, Part 2 - Encapsulation Scope

PeterRitchie — Thu, 08 May 2008 20:01:00 GMT

Let's look at the ubiquitous Person concept. It might seem logical that an application that deals with people should have a Person interface for classes to implement. For example:

public interface IPerson
{
                String GivenName { get; set; }
                String SurName { get; set; }
                IAddress Address { get; set; }
}

At first glance this seems fine. The IPerson interface defines attributes that the application uses with most scenarios dealing with types of IPerson, it's "well encapsulated". But, the person concept is much more broad than what IPerson is modeling. IPerson hasn't fully encapsulated the person concept. A person could have parents, age, weight, height, etc. The application doesn't need this information so it's narrowed the concept of person to fit its needs. This is an incomplete abstraction. The type that the application needs (that is currently IPerson) should be fully abstract. Based on the IPerson interface, a better abstraction would be ILocatableIndividual.

Let's look at the opposite of not fully encapsulating a concept.

Let's look at another common concept, the Invoice:

public class Invoice
{
                Customer BillToCustomer { get;set; }
                Customer ShipToCustomer { get;set; }
                Datetime InvoiceDate;
                ICollection<InvoiceItem> InvoiceItems { get; }
                Single ShippingAndHandlingPrice { get; set; }
                Single CalculateSubTotal();
                Single CalculateTotal();
                Single CalculateGrandTotal();
                PurchaseOrder PurchaseOrder { get; set; }
                void Print();
}

Again, seems like a reasonable encapsulation; but it has an issue.

There's a fundamental principle of OOD called the Single Responsibility Principle. Robert Martin interprets the principle as "there should never be more than one reason for a class to change.". A class should model a single abstraction. For that abstraction to remain abstract the modeled class should have a single responsibility. In the case of Invoice, the invoice concept should only model behaviours and attributes of an invoice. An invoice does not print, something or someone else prints it. With the above Invoice definition should printing need to change Invoice must also change, event though what the invoice *is* doesn't change. Invoice is now coupled to how printing occurs. In Martin's terms, Invoice now has two reasons for it to change: when invoice attributes change, and when how printing occurs changes.

The Invoice class should be refactored by moving the Print method to another class. Likely this would involve MVC, or MVP where a view would be responsible for the "printed view" and a controller or presenter would be responsible for communicating with the model (Invoice).

Fundamentals of Object-Oriented Design (OOD) Part 1

PeterRitchie — Fri, 02 May 2008 03:50:00 GMT

With increased usage of patterns and situationally specific strategies, people sometimes lose sight of the concepts and principles behind these patterns and strategies and fail to follow them when they're not using patterns or strategies. I feel it's good to periodically review the fundamental concepts and first principles.

Object Oriented Design (OOD) attempts to help with the complexity of designing, writing, and maintaining software. It attempts to allow building of software by modeling real-world objects. As with any tool, it can be used improperly, but OOD attempts to facilitate simplicity, robustness, flexibility, etc.. OOD has many fundamental concepts. Some of these concepts include modularity, encapsulation, and abstraction. OOD deals with modeling behaviour and attributes of real-world objects.

Modularity is a technique of composing software from separate parts. At the lowest level of an Object-Oriented Programming Language (OOPL), this is the definition of a type (a class or a struct in C#/C++). Depending on the platform there may be various other levels of modularity. In C#, for example, modularity can occur at other levels like module (source file), namespace, netmodule, assembly, etc. Modularity is a form of encapsulation.

Encapsulation is a technique of hiding implementation details, grouping them together. In OOPL, the lowest level of encapsulation is the type level (again, class/struct in C#/C++). Implementation details (data) is separated from behaviour of a type. In some OOPLs both behaviour and attributes (properties, for example in C#) are separated from behaviour. This allows clients to decouple or to be not dependant on those implementation details. Encapsulation is a form of abstraction.

The ability to encapsulate related behaviour, attributes, and implementation allows programmers to utilize abstraction. Abstraction facilitates separation. OOPLs allows programmers to keep concepts separate by abstracting them from one another. Keeping abstract concepts separate allows these concepts to evolve and be used independently. Properly designed types allow abstraction; a File class can abstract the file system away from a particular file, for example. The file system is part-and-parcel when dealing with files; but while dealing with a File object, it is abstracted away.

Good OOD has as little dependencies between parts as possible. This is called lack of coupling. One part that uses another part means the part depends on that other part. Changes to the second affect the first. Good OOD also has parts that contain related behaviour and attributes. This is called cohesion. If all the behaviour and attributes are generally used together in each scenario, the part has high cohesion. If only some behaviour or attributes are used in each scenario, the part has low cohesion and likely should be split up. Some people only view cohesion and coupling at the class level, I've purposely said "part" because I believe these concepts need to live throughout the modeled system, from class-level details, to modules, to namespace, to assemblies, to layers, to components, to systems, etc.

I will continue this series with the fundamental OOD principles that all good patterns should enforce.

Overcoming problems with MethodInfo.Invoke of methods with by-reference value type arguments

PeterRitchie — Tue, 29 Apr 2008 14:08:00 GMT

I ran into an interesting problem on the Forums recently. Basically, when you use MethodInfo.Invoke to invoke a method with by-reference value type arguments you can't have the invoked method update a variable/argument. The problem is, when you invoke the method the parameter is passed to the MethodInfo.Invoke via an object array. Since we're dealing with a value type, the original value type is boxed and the invoked method actually updates the array element, not the original object (as it would with reference types). For example:

using System;
using System.Reflection.Emit;
using System.Reflection;
using System.Diagnostics;
 
namespace InvokeTesting
{
    class Program
    {
        private const int testValue = 10;
        public static void TestMethod(ref int i)
        {
            i = testValue;
        }
        static void Main(string[] args)
        {
            MethodInfo methodInfo = typeof (Program).GetMethod("TestMethod", BindingFlags.Static | BindingFlags.Public);
            int i = 0;
            object[] parameters = new object[] {i};
            methodInfo.Invoke(null, parameters);
            // original variable isn't updated
            Debug.Assert(i == 0);
            // array element is updated:
            Debug.Assert((int)parameters[0] == testValue);
 
            // copy updated value to original variable
            i = (int)parameters[0];
 
            Debug.Assert(i == testValue);
        }
    }
}

Of course, the only "workaround" is to get the new value out of the array.

Since essentially we're implementing a run-time method invocation, a "better" way would be to create a dynamic method to make the call. A dynamic method is a method created at run-time (whose body is generated through ILGenerator.Emit et al) and invoked via a delegate. For example:

using System;
using System.Reflection.Emit;
using System.Reflection;
using System.Diagnostics;
 
namespace EmitTesting
{
    // delegate for void method that takes one reference parameter
    public delegate void OneRefParameterCallback<T>(ref T value);
 
    class Program
    {
        private const int testValue = 10;
        public static void TestMethod(ref int i)
        {
            i = testValue;
        }
        static void Main(string[] args)
        {
            // create a dynamic method object with arbitrary name "Caller", void return (null), and one parameter "ref int"
            DynamicMethod caller = new DynamicMethod("Caller", null, new Type[] { typeof(int).MakeByRefType() }, typeof(Program).Module);
 
            ILGenerator ilGenerator = caller.GetILGenerator();
 
            // emit ldarg.0
            ilGenerator.Emit(OpCodes.Ldarg_0);
 
            // emit call void EmitTesting.Program::TestMethod(int32&)
            MethodInfo mi = typeof(Program).GetMethod("TestMethod", BindingFlags.Static | BindingFlags.Public, null,
                                                    new Type[] { typeof(int).MakeByRefType() }, null);
            ilGenerator.Emit(OpCodes.Call, mi);
 
            // emit ret
            ilGenerator.Emit(OpCodes.Ret);
 
            OneRefParameterCallback<int> callback =
                (OneRefParameterCallback<int>)caller.CreateDelegate(typeof(OneRefParameterCallback<int>));
 
            // call our emitted code with a reference parameter
            int i = 0;
            callback(ref i);
            Debug.Assert(i == testValue);
        }
    }
}

In this example, the method invocation directly updates a value type variable. This could be made more re-usable to refactoring the dynamic method creation code into it's own method.

Upcoming C# 3 Guidance From Microsoft

PeterRitchie — Thu, 13 Mar 2008 15:46:00 GMT

Mircea Trofin has some design guidelines with regard to some C# 3 language additions (that I assume will make it into a revised Framework Design Guidelines of some sort). They more less agree with the guidelines I published in Code Magazine a while ago. There are some slight differences:

Consider using extension methods in any of the following scenarios: to provide helper functionally relevant to every implementation of an interface... and,

Do define extension methods in the same namespace as the extended type, if the type is an interface, and if the extension methods are meant to be used in most or all cases. This applies to framework designers that are publishing interfaces but also want to publish callable methods that apply to all implementation of those interfaces. My article approaches the guidelines more from a non-framework designer. I do agree that extension methods to extend interfaces is very useful and is probably one of the most adept use of extension methods. Although, I think the wording of this guideline could use improvement.

Avoid defining extension methods on System.Object, unless absolutely necessary. Good advice.

Do not define extension methods pertaining to a feature in namespaces normally associated with other features. Instead define them in the namespace associated with the feature they belong to, or a namespace of it. This is really unclear (and seems to suggest contradicting the first guideline: Avoid frivolous use of the extension methods feature when defining methods on a new type. Use the canonical, language-specific means for defining type members). I'm assuming the jist of this is, as a framework designer, don't arbitrarily put extension methods in the namespace of the type the method applies to, consider putting the extension method in a more applicable namespace, if possible. For example, if you want to declare an extension method "Forward" for Telecom.INode implementations, putting the method in a "Routing" namespace would be better than arbitrarily putting it in the "Telecom" namespace. I've changed the Mircea's guidance slightly to use a interface in the example--which I think makes it more clear.

Mircea also includes Consider using extension methods in any of the following scenarios:... when object model considerations would dictate taking a dependency on some assuming but taking such a dependency would break dependency management rules. This means, should you need to add a method to a class but adding that method would create cyclic dependency or would cause a lower level assembly/class to be dependant on a higher level class, break the method out into another assembly as an extension method. Use this advice with caution; I would argue that if you think you need a method like this at all (even if implemented as an extension method), you likely have some design problems and should only be considered when revising a published framework, and not when creating a new framework.

Another tidbit of guidance that came about after I wrote the article and Mircea doesn't mention is that extension methods can make writing fluent interfaces much cleaner by separating the state management concern of supporting a fluent interface from the class that it applies to.

Thoughts? Any additional guidance you feel has been overlooked (with regard to extension methods and LINQ)?

"Object is currently in use elsewhere" error.

PeterRitchie — Mon, 28 Jan 2008 17:04:00 GMT

I was debugging what I thought was a strange exception the other day. The exception was an InvalidOperationException and the message was "Object is currently in use elsewhere". Unless you're familiar with this exception, it really doesn't offer much as to why the exception is occurring. There seems to be several stale threads on the Web about this issue, so I'd thought I'd post about it.

As it turns out it had to do with some code that was PInvoking some native graphics functions and the interaction with the WinForm that was hosting the drawing surface was to blame.

What's really happening with "Object is currently in use elsewhere" is that GDI+ is complaining that the device context (DC) that it is trying to use is already "in use". With WinForms, this generally means there is a recursive Graphics.GetHdc occurring. GetHdc must match a ReleaseHdc before any other GetHdc. Recursive means you have something like GetHdc->GetHdc->ReleaseHdc->ReleaseHdc, instead of GetHdc->ReleaseHdc->GetHdc->ReleaseHdc. Another possibility is that there is a missing call to ReleaseHdc. (i.e. GetHdc->GetHdc->ReleaseHdc)

Now, in my case there was some seemingly innocuous code like this:

    SafeNativeMethods.DrawSomeStuff(e.Graphics.GetHdc(), parameters);
    e.Graphics.DrawString(text, this.Font, Brushes.Black, point);

...no matching ReleaseHdc(), before the DrawString call.

The fix turned out to be really simple:

    try
    {
        SafeNativeMethods.DrawSomeStuff(e.Graphics.GetHdc(), parameters);
    }
    finally 
    {
        e.Graphics.ReleaseHdc();
    }
    e.Graphics.DrawString(text, this.Font, Brushes.Black, point);

You can also encounter this exception if you're drawing to a form from multiple threads. You'll likely also be encountering a cross-threading exception as well. The solution in this case is to not use multiple threads when accessing a form, including drawing.

Formatting/parsing for a specific culture redux

PeterRitchie — Tue, 22 Jan 2008 23:35:00 GMT

In recent blog post I detailed how creating a culture via the CultureInfo constructor could actually create a user-overridden culture--which could be completely different than the culture that you've requested by name. Fortunately there's a way of overriding the user override (apologies for overloading "override") by supplying the boolean value "false" in a CultureInfo overload.

As Greg Beech commented, there's another method to create a culture--System.Globalization.CultureInfo.CreateSpecificCulture. This sounds like it does exactly what you might expect and creates a "specific" culture. Unfortunately, this method too violates the principle of least astonishment and creates a culture that uses the user-overridden values when the culture name matches that of the user's current culture.

CreateSpecificCulture does not, as far as I can tell, have an overload/alternative to you allow to to force a "specific" culture, so the problem is much worse with CreateSpecificCulture. I've gone ahead and logged a bug for it on Connect: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=321241

In case you're wondering why this is more serious, consider the following following block of code that formats a date value as text:

System.Globalization.CultureInfo ci;

String text;

ci = System.Globalization.CultureInfo.CreateSpecificCulture("en-us");

text = String.Format(ci, "{0:d}", DateTime.Now);

And that text is transmitted to another application (or another session of the same application, e.g. serialization), potentially in another locale, to be parsed with the following block of code:

System.Globalization.CultureInfo ci;

ci = System.Globalization.CultureInfo.CreateSpecificCulture("en-us");

String text = ReadRecord();

DateTime now = DateTime.Parse(text, ci);

If either (or) the user's current culture is set to "English (United States)" and they've overridden the currency format the short date (say from "M/d/yyyy" to "d/M/yyyy") will randomly result in the wrong date.

Formatting/parsing for a specific culture

PeterRitchie — Thu, 27 Dec 2007 15:47:00 GMT

Sometimes you may want to use a specific format for formatting and parsing of textual data. The easiest way to do this is to select a specific culture and use that with formatting and parsing methods. Unfortunately, the CultureInfo constructor that just takes the name of the culture defaults to accepting any overrides the current user has set in Regional and Language Options.

For example, if in Regional and Language Options you have English (United States) selected and you've changed the currency symbol to be something other than the dollar sign ($), the following won't use the dollar sign:

            Decimal d = 2123.5M;

            String text = String.Format(new System.Globalization.CultureInfo("en-us"), "{0:c}", d);

If you want to use a specific culture, you must use the CultureInfo constructor overload that accepts a Boolean so you can tell it not to use the user overrides. For example, the following will result in a dollar sign, despite what the user has done in Regional and Language Options:

            Decimal d = 2123.5M;

            String text = String.Format(new System.Globalization.CultureInfo("en-us", false), "{0:c}", d);