Visual Studio 在不需要时建议完全限定的命名空间

本文关键字：命名空间 Studio 不需要 Visual | 更新日期: 2023-09-27 18:31:59

对于Visual Studio 2010（也可能是2008），我注意到Intellisense会建议枚举的完全限定命名空间的行为。

例如，我可以编写这样的代码：

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

但是当我尝试写它时，它建议我这样写：

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

这些不必要的额外代码确实会加起来并使其可读性降低，我必须基本上与 Intellisense 作斗争才能避免它。

我有理由吗？ 我可以关闭它吗？ 我假设原因是枚举的名称与属性的名称相同。 但这真的不是一个很好的理由。

编辑：

下面是另一个示例，演示了为什么不需要完全限定的命名。

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

Visual Studio 在不需要时建议完全限定的命名空间

我想你正在WPF环境中工作（我看到元素），并且你以某种方式引用了System.Windows.Forms dll。

我的推论是基于可以在两个命名空间中找到HorizontalAlignment的事实：

in System.Windows.Forms.HorizontalAlign

和

in System.Windows.FrameworkElement.HorizontalAlign

有两个指向同一类型的引用，VS 要求指定您确切的意思命名空间。

这

似乎确实与属性和type.
的名称相同。这是模仿事物的最小可重现示例（可能更小，但这揭示了更多）......

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

MyEnum和TestEnum属性（目标TestEnum枚举）都提供"完全限定"的名称（其他名称与其属性类型不同，但类型与其他属性的名称匹配，因此两者都是"污点"）-而SndTestEnum具有不同的命名（类型，属性），并且在任何一种情况下都可以正常工作。

。有趣的是，即使您删除namespace MyCallerNS并将其全部放在"长命名空间"下 - 它仍然会在前面添加AndSomeMore.。

在我看来没有解决方案（缺少 Re# 和 3rd 方工具），
这似乎是智能感知不像编译器案例那样智能，正如@Rick所建议的那样。

或者更确切地说 - 编译器需要时间来解决问题（手头有所有信息），而 IntelliSense 没有那种"深度"和对事物的洞察力（我猜，真的很简化 - 我们需要对此进行@Eric：）并做出快速/最简单的选择。

实际上，根据我之前的想法，
它更多的是关于每个执行的"工作" - 并且 IntelliSense（作为完成"服务"）必须为您提供列表中的所有选择（属性名称和类型）（我没有看到它们都存在，但猜测。并且有一个选择来涵盖两者可能会很痛苦）
因此，为了区分它，添加了完全限定的名称.
它"失败"（某种程度上）的地方是最终"粘贴"简短版本"——我确实应该认为。

我发现如果我输入element.HorizontalAlignment =那么VS2010将自动建议System.Windows.HorizontalAlignment如果您按Tab键，则会选择哪个。 如果不按 Tab 键，而是键入"Ho"以缩小列表范围，然后按 Tab，则只会获得水平对齐。

如果您能够使用Resharper，那么在键入"= "后，您将看到最明显的选择：

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

在这种情况下，编译器比智能感知更智能。

如果您正在访问与其类型同名的属性，例如"公共文本对齐文本对齐 { get;设置;}"，则无需完全限定分配给它的枚举值的命名空间。但是，Intellisense似乎不够聪明，无法知道这一点。代码在没有限定的情况下可以正常工作，您只需要善于注意和躲避智能感知即可。

除了上面的答案之外，我还有一些涉及Microsoft办公自动化的项目。我的课程结构为

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

当尝试访问 .NET 框架本身的 Microsoft 命名空间中的任何内容时，智能感知将强制您完全限定名称。在根冲突的情况下，它还会在全局关键字前面加上，如下所示：global::Windows.Forms.etc... 。

相关文章：