一个空命名空间的C#类

Question

在查看一些旧代码时，我发现可以声明一个C#类而不将其放置在命名空间中（在这种情况下，我有一个ASP.NET WebForms应用程序，其中一些Web表单没有声明在任何命名空间中）。

对这样的类执行GetType()会返回一个类型，其中namespace属性设置为null。

我不知道这是允许的——有人能否建议为什么要有一个未声明在命名空间中的类呢？

- Richard Ev

---

哦，我不知道。我经常创建一些不（明确）存在于类或命名空间中的东西，但是反过来说，我正在使用微小的hackish动态语言 ;) - user395760

Answer 1

这并不是一个很好的实践。这确实使一些例子更容易，比如“hello world” - 也许C#的设计人员正在进行代码高尔夫比赛; p 但是，确实存在一种奇怪的情况。我不知道我们是否需要直接使用全局名称空间的明显原因。即使对于扩展方法，我也宁愿添加一个“using”指令来引入它们...

有趣的是 - 在mscorlib.dll中似乎有40多个这样的，在system.dll中有20多个。

var mscorlib = typeof(string).Assembly.GetTypes()
   .Where(t => string.IsNullOrEmpty(t.Namespace)).ToList();
var system = typeof(Uri).Assembly.GetTypes()
   .Where(t => string.IsNullOrEmpty(t.Namespace)).ToList();

（但所有私有/编译器生成的）

- Marc Gravell

---

我能想到的唯一理由是使简单示例更简单。但是命名空间的概念本身相当简单，而且也是一个相当基础的概念... - Richard Ev

Answer 2

也许是为了与不支持命名空间的语言进行互操作性。

更新

经过一番调查，我发现微软有一个用例。

所有.Net Framework程序集都在全局命名空间中拥有一些标准类，例如：

- FXAssembly：版本信息。 - ThisAssembly：程序集信息。 - AssemblyRef：依赖程序集信息。

这些类包含预设的元数据，否则获取它们将更加困难和昂贵。我猜想他们选择将这些类定位在全局命名空间中，以便它们成为工具、实用程序等可以获取的标准/常规位置。这些信息是引导/元信息，因此在命名空间概念之上逻辑上位于其上方。

- Tim Lloyd

---

看起来可能，但我不禁在想，任何这样的语言在与BCL交流时都会受到很大限制。 - Marc Gravell