C#：为什么第一个命名空间是多余的？

Question

这有点吓人。

我想一定有某个地方可以解释为什么会发生这种情况。

在我们的解决方案中，大约有 50 个不同的项目。大多数情况下，这些库以命名空间 OurCompany 开头。

我们有 OurComany.This.That 和 OurCompany.Foo.Bar... 等。

外部库与命名空间之间存在命名空间/类冲突

OurCompany.Foo.Bar

还有一个像这样合格的班级..

OurCompany.Some.Location.Foo

错误是这样的：

Error   75  The type or namespace name 'MethodName' does not exist in the
namespace 'OurCompany.Foo' (are you missing an assembly reference?)

当我完全限定“OurCompany”命名空间下的任何内容时，即使 Resharper 也会给我一个“限定符是多余的”消息......即

OurCompany.Some.Location.Foo.MethodName();
//OurCompany is redundant

我无法弄清楚到底是什么在这样做。解决方案非常庞大，因此将问题拆分并尝试对问题进行逆向工程对我来说并不是一个很好的解决方案。

我应该声明，如果我使用...

Some.Location.Foo.MethodName(); //Leaving out OurCompany

...Resharper 消息消失。

Answer 1

我以为我明白这里发生了什么，但现在我看到了一些奇怪的行为，这让我质疑我对 C# 的命名空间作用域行为的理解。

显然，基本问题是范围界定。据推测，您正在OurCompany 下的某个命名空间中处理某些东西；我们只是说为了争论，你在OurCompany.This.That。自动地，任何直接在 OurCompany.This.That、OurCompany.This 和 OurCompany 命名空间中找到的类型或命名空间都在范围内，无需使用。这就是为什么一旦涉及带有 OurCompany.Foo 命名空间的程序集（OurCompany 中的所有内容默认情况下都在范围内，包括 Foo 命名空间和命名空间 [显然] 优先），事情就会崩溃，也是为什么你重新收到冗余命名空间警告（Some 命名空间在 OurCompany 命名空间中定义，因此它自动在范围内）。

但试图重现这种行为，我遇到了一些奇怪的事情。我创建了一个文件来保存相关世界的其余部分：

namespace OurCompany
{
    namespace Some
    {
        namespace Location
        {
            public class Foo
            {
                public static void MethodName() { }
            }
        }
    }

    namespace Foo
    {
        namespace Bar { }
    }
}

发现以下（我收集到的与您正在做的类似）不起作用：

using OurCompany.Some.Location;

namespace OurCompany
{
    namespace This
    {
        namespace That
        {
            class BeepBoop
            {
                private void DoSomething()
                {
                    Foo.MethodName();  // No good; Foo is a namespace here.
                }
            }
        }
    }
}

...但是这样做了：

namespace OurCompany
{
    namespace This
    {
        namespace That
        {
            using OurCompany.Some.Location;
            class BeepBoop
            {
                private void DoSomething()
                {
                    Foo.MethodName();  // Puh-wha?  This works?
                }
            }
        }
    }
}

我坦率地承认我不知道这里发生了什么。但显然，范围并不像“范围内的任何内容都在范围内，并且命名空间优先”那么简单。

Answer 2

每当我引用的 dll 未构建时，我都会看到此错误。引用可能未构建并且存在一些构建错误。因此，Resharper 和 VS 都在抱怨缺少的类型。

为了修复它，我建议您执行以下操作：

1. 在 50 个项目的解决方案中尝试找出基础项目。您可以使用项目构建顺序（在解决方案资源管理器中右键单击 sln）
2. 禁用所有其他项目并点击构建。
3. 现在验证构建是否成功。如果构建不成功，请修复错误。如果成功，从步骤 1 开始重复。

我知道这很乏味，但我认为这是修复您看到的大量 (#3000) 错误的好方法。