Visual Studio suggesting fully qualified namespaces when not needed

Question

With Visual Studio 2010 (possibly 2008 as well) I am noticing behavior where Intellisense will suggest the fully qualified namespace for enums.

For example, I can write code like this:

element.HorizontalAlignment = HorizontalAlignment.Right;
element.VerticalAlignment = VerticalAlignment.Bottom;

But when I try to write it, it suggests I write it like this:

element.HorizontalAlignment = System.Windows.HorizontalAlignment.Right;
element.VerticalAlignment = System.Windows.VerticalAlignment.Bottom;

This unnecessary extra code can really add up and makes it less readable, and I have to basically fight with Intellisense to avoid it.

Is there I reason for this? Can I just turn it off? I assume the reason is that the name of the enum is the same as the name of the property. But that's really not a good reason.

EDIT:

Here's another example that demonstrates why fully qualified naming is not necessary.

using SomeOtherNamespace;

namespace SomeNamespace
{
    public class Class1
    {
        public Class2 Class2 { get; set; }

        public Class1()
        {
            // These all compile fine and none require fully qualified naming.  The usage is context specific.
            // Intellisense lists static and instance members and you choose what you wanted from the list.

            Class2 = Class2.Default;
            Class2.Name = "Name";
            Class2.Name = Class2.Default.Name;
            Class2 = Class2;
        }
    }
}

namespace SomeOtherNamespace
{
    public class Class2
    {
        public static Class2 Default { get; set; }

        // public static Class2 Class2;  (This throws an error as it would create ambiguity and require fully qualified names.)

        // public static string Name { get; set; }  (This also throws an error because it would create ambiguity and require fully qualified names.

        public string Name { get; set; }
    }
}

Answer 1

I suppose you are working in WPF environment (I see element) and you have somehow the reference to System.Windows.Forms dll.

My deduction is based on fact that HorizontalAlignment can be found in both namespaces:

in System.Windows.Forms.HorizontalAlignment

and

in System.Windows.FrameworkElement.HorizontalAlignment

Having two references pointing to the same type, VS asks to specify what namespace exactly you mean.

Answer 2

This indeed seems to be the same name for property & the type.
Here is the smallest reproducible example that mimics things (could be smaller but this reveals more)...

namespace Company.Project.SubProject.Area.Test.AndSomeMore
{
    public class TestClass
    {
        public TestEnum MyEnum { get; set; }
        public TestEnum TestEnum { get; set; }
        public SndTestEnum NewEnum { get; set; }
    }
    public enum TestEnum
    {
        None,
        One,
        Two
    }
    public enum SndTestEnum
    {
        None,
        One,
        Two
    }
}
namespace MyCallerNS
{
    public class MyTestClass : TestClass
    {
        public MyTestClass()
        {
            this.TestEnum = Company.Project.SubProject.Area.Test.AndSomeMore.TestEnum.One;
            this.MyEnum = Company.Project.SubProject.Area.Test.AndSomeMore.TestEnum.Two;
            this.NewEnum = SndTestEnum.None;
        }
    }
}

Both MyEnum and TestEnum properties (targetting TestEnum enum) offer 'fully qualified' names (other has different name than its property type but the type matches other property's name, so both are 'tainted') - while SndTestEnum has different naming (for type, property) and works fine in either case.

...funny thing is that even if you remove namespace MyCallerNS and put all under the 'long namespace' - it'd still add AndSomeMore. in front.

There is not solution as I see it (short of Re# and 3rd party tools),
this seems to be the IntelliSense not being as smart as the compiler case, as @Rick suggested.

Or rather - compiler takes its time to resolve things (with all the info at hands), while IntelliSense does not have that 'depth' and insight into things (I'm guessing, simplifying really - we need @Eric on this:) and makes fast/easiest choices sort of.

Actually, on my previous thought,
it's more about the 'job' that each perform - and IntelliSense (as a completion 'service') has to present you with all the choices (both the property name and the type) in the list (I don't see them both being present, but a guess. And having one choice to cover both would probably be a pain to handle)
So to differentiate it adds the fully qualified names.
And where it 'fails' (sort of) is to 'paste' the 'short version' in the end - which indeed it should I think.

Answer 3

I find if I type element.HorizontalAlignment = then VS2010 will automatically suggest System.Windows.HorizontalAlignment which will be selected if you press the tab key. If instead of pressing the tab key you type 'Ho' to narrow the list, and then press tab, you will just get HorizontalAlignment.

If you are able to use Resharper, then after typing '= ' you will be presented with the most obvious choices of:

HorizontalAlignment.Center
HorizontalAlignment.Left
HorizontalAlignment.Stretch
HorizontalAlignment.Right

Answer 4

This is a case where the compiler is smarter than Intellisense.

If you're accessing a property with the same name as its type, e.g. "public TextAlignment TextAlignment { get; set; }", you don't need to fully qualify the namespace of the enum value being assigned to it. But, Intellisense doesn't seem smart enough to know this. The code will work fine without the qualification, you just have to get good at noticing and dodging Intellisense.