为什么导入需要项目名称而不仅仅是对象？答案

【问题标题】：Why does import need the project name and not just the object?为什么导入需要项目名称而不仅仅是对象？
【发布时间】：2014-08-28 15:33:44
【问题描述】：

我花了一段时间才理解我要描述的问题，所以如果描述令人困惑，请告诉我......

我有一个名为“cProp”的对象，它定义了许多子类。要在项目的其他文件中引用这些类，我必须执行类似...

Dim cp = New cProp.InflationRow()

我明白为什么会这样；由于 InflationRow 在 cProp“内部”，我需要告诉它在哪里可以找到它。很好。

但这当然会变得乏味，所以有时你想修复它......

Imports cProp

为什么这不起作用？为什么我必须...

Imports ProjectName.cProp

您可能想知道我为什么关心这些文件，但这些文件用于许多不同名称的项目中。因此，如果我使用 Imports，我必须在很多地方更改项目名称。我知道命名空间可能是我想要的解决方案，对吧？

我的困惑源于编译器可以很好地确定我在代码中指的是哪个 cProp（这是唯一的），那么为什么不在 Imports 中呢？我想我在这里遗漏了一些基本的东西。

【问题讨论】：

因为语言是这样设计的，所以项目实际上是一个命名空间 :) msdn.microsoft.com/en-us/library/aa711891(v=vs.71).aspx 顺便说一句，C# 很多 less generous
当然可以，但是为什么我需要将命名空间放在 Imports 中，而不是放在代码本身中？
> " these files are used in numerous projects with different names." -- 是时候将它们移到自己的程序集中了。

【解决方案1】：

这是因为您的项目有一个根命名空间 - 您可以在项目属性中看到它。您可以在项目属性中删除它 - 这将导致您可以简单地使用另一个项目中的类名。但是，命名空间是组织类的好方法。在 VB 中，项目默认具有根命名空间，您在代码文件中看不到它。

在您的项目中，由于它似乎都在同一个根命名空间内，因此您不必使用根命名空间来限定根命名空间内的代码。 “Imports”语句不在命名空间内（只有类型可以在命名空间内）——这就是为什么你必须在那里提供完整的限定条件。

【讨论】：

我认为最后一句话可能是我困惑的根源。因此，如果我理解此声明，您是说 Friend 类具有默认命名空间，但它上面的 Imports 没有？如果是这样，我觉得这有点与 Imports 的整个想法背道而驰，但它确实解释了它。
是的 - 项目中的每个类型都有一个根项目级命名空间，都在该命名空间中（如果您使用任何“命名空间”语句，可能嵌套在多个命名空间中）。但是，“Imports”不会出现在类型中——它们需要完全限定，因为这些语句不在任何命名空间中。