Visual Studio suggerisce spazi dei nomi completi quando non necessario

Question

Con Visual Studio 2010 (probabilmente anche il 2008) noto un comportamento in cui Intellisense suggerisce lo spazio dei nomi completo per le enumerazioni.

Per esempio, posso scrivere codice come questo:

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

Ma quando provo a scriverlo, suggerisce scrivo in questo modo:

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

Questo codice aggiuntivo non necessario può davvero sommare e renderlo meno leggibile, e devo sostanzialmente combattere con Intellisense per evitarlo.

C'è un motivo per questo? Posso semplicemente spegnerlo? Presumo che la ragione sia che il nome dell'enumerazione è lo stesso del nome della proprietà. Ma non è davvero una buona ragione.

EDIT:

Ecco un altro esempio che dimostra perché pienamente qualificato di denominazione non è necessario.

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

Questo sembra essere lo same name for property & the type.
Ecco il smallest reproducible example che imita le cose (potrebbero essere più piccole, ma questo rivela più) ...

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; 
     } 
    } 
} 

Sia MyEnum e TestEnum proprietà (rivolte TestEnum enum) offerta nomi 'pienamente qualificati' (altro ha nome diverso da quello il suo tipo di proprietà ma il tipo corrisponde al nome di altre proprietà, quindi entrambi sono "macchiati") - mentre SndTestEnum ha nomi diversi (per tipo, proprietà) e funziona in entrambi i casi.

... la cosa divertente è che anche se si rimuove namespace MyCallerNS e si inserisce tutto nello spazio dei nomi lungo, aggiungere ancora AndSomeMore. nella parte anteriore.

Non c'è soluzione, come la vedo io (a corto di Re # e strumenti 3rd party),
questo sembra essere l'IntelliSense non essere as smart as the compiler caso, come suggerito @Rick.

O meglio: il compilatore prende tempo per risolvere le cose (con tutte le informazioni a portata di mano), mentre l'intellisense non ha quella "profondità" e intuizione delle cose (sto indovinando, semplificando davvero - abbiamo bisogno di @Eric su questo :) e rende le scelte più veloci/più semplici.

EDIT: In realtà, il mio pensiero precedente,
è più circa il 'lavoro' che ogni eseguire - e intellisense (come un 'servizio' di completamento) deve presentare con tutte le scelte (sia la proprietà nome e tipo) nell'elenco (non vedo che siano presenti entrambi, ma una supposizione e avere una scelta per coprire entrambi sarebbe probabilmente un problema da gestire)
Quindi per differenziare aggiunge i nomi completi.
E dove "fallisce" (sorta di) è quello di "incollare" la "versione breve" alla fine - che in effetti dovrei pensare.

Answer 2

ho suppongo si sta lavorando in WPF ambiente (vedo elemento) e si dispone di qualche modo il riferimento a System.Windows.Forms dll.

mia deduzione si basa sul fatto che HorizontalAlignment possono essere trovati in entrambi gli spazi dei nomi:

in System.Windows.Forms.HorizontalAlignment

e

in System.Windows.FrameworkElement.HorizontalAlignment

Avere due riferimenti che puntano allo stesso tipo, VS chiede di specificare quale spazio dei nomi corrisponde esattamente a.

Answer 3

Se trovo il tipo element.HorizontalAlignment =, VS2010 suggerirà automaticamente System.Windows.HorizontalAlignment che verrà selezionato se si preme il tasto Tab. Se invece di premere il tasto tab, digita 'Ho' per restringere l'elenco, e quindi premi tab, otterrai solo HorizontalAlignment.

Se siete in grado di utilizzare Resharper, poi, dopo la digitazione '=' ti verrà presentato con le scelte più ovvie di:

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

Answer 4

questo è un caso in cui il compilatore è più intelligente di Intellisense.

Se si accede a una proprietà con lo stesso nome del tipo, ad es. "public TextAlignment TextAlignment {get; set;}", non è necessario qualificare completamente lo spazio dei nomi del valore enum che gli viene assegnato. Ma Intellisense non sembra abbastanza intelligente per saperlo. Il codice funzionerà bene senza la qualifica, devi solo essere bravo a notare e schivare Intellisense.

Answer 5

In aggiunta alle risposte precedenti, ho avuto alcuni progetti in cui è stata coinvolta l'automazione di Microsoft Office.Le mie lezioni erano strutturate come

• CustomNameSpace.Library.Microsoft.Word.CustomClass1
• CustomNameSpace.Library.Microsoft.Excel.AnotherCustomClass

Quando si cerca di accedere a qualsiasi cosa all'interno del namespace Microsoft .NET framework stesso, Intellisense si costringerebbe a qualificare completamente i nomi. In caso di conflitto di root, farebbe anche precaricare la parola chiave globale in questo modo: global::Windows.Forms.etc....