Peter Ritchie's MVP Blog : Product Bugs

Drag-copying in Visual Studio Solution Explorer.

PeterRitchie — Fri, 18 Jul 2008 16:46:00 GMT

NOTE: I've tried this in Visual Studio 2008 (VS2k8), I'm assuming the same thing happens in Visual Studio 2005 (VS2k5).

In the process of refactoring, it's *very* common for me to rename a type. This is most easily done by renaming the file in the Solution Explorer (SE)--which renames the file, the type, and and any uses of the type in the entire solution.

Occasionally, I need to create a new type based on another. Copying an abstract type in order to implement the abstract type is often handy--I just fill in the abstract members (and delete "abstract") in the copied type after renaming it.

Drag-copy in the SE seems like it would take care of a couple of steps at once for me: make a copy and rename it. Unfortunately it doesn't do that. It makes a copy of the file (as "Copy of typename.xx") but doesn't rename any types in the class that match the file name.

This might seem somewhat trivial... I can simply rename the file name then refactor rename the type in the file so that the type and all it's constructors are renamed in one fell swoop. Alas, this simply opens a can of worms that can completely confound a newcomer and annoy an expert.

That simple, intuitive method of renaming a copy of a file then the type within the file actually renames *all* types of that name. Since we've just made a copy of the type, that means it's always going rename types in two files. The side-effect of drag-copy in SE means you *must* manually rename the type in the file you just copied. You can do this with search-replace; but that's friction I don't want and really makes SE drag-copy unusable.

I've logged a bug about it on Connect; but the olde "by design" card was played...

Resharper Isn't Always Smart

PeterRitchie — Mon, 31 Mar 2008 17:47:00 GMT

I was writing some code today, essentially like this:

public class MyClass
{
    private int value;
    public MyClass(int value)
    {
        this.value = value;
    }
    public static bool operator==(MyClass left, MyClass right)
    {
        return left.value == right.value;
    }
 
    public static bool operator !=(MyClass left, MyClass right)
    {
        return !(left == right);
    }
}

    //...
    MyClass myClass1 = new MyClass(1);
    MyClass myClass2 = new MyClass(1);
    if((Object)myClass1 != (Object)myClass2) // "Type cast is reundant"
    {
        Console.WriteLine("not equal");
    }
    else
    {
        Console.WriteLine("equal");
    }

...where Resharper warned that both the casts to Object were redundant and offered a "Quick-fix" (red light bulb) to "Remove cast". Well, doing that to one of the casts results in a compile error so you have to manually change the other; but what it's suggesting is this:

    if(myClass1 != myClass2)

This completely changes the output of my application from "not equal" to "equal". What Resharper doesn't know (or doesn't care to check) is that removing those casts switches from a reference comparison to a value comparison and may have different results. What I wrote with the original code was to test if the two references referenced the same object. The default behaviour of a class is to do a reference check; but I've overloaded operator== (and operator !=) to perform a value comparison (I've left out the lovely bits that truly gives MyClass value semantics for clarity).

So, when Resharper offers to change your code, be sure you know side-effects of that change before you let it do it. You could introduce a nasty bug.