VBA相当于使用C＃或VB.NET导入/创建别名
基础参考： VBA，Visual Basic .NET和C＃的十个代码转换
注意： 我已经创建并导入了一个*.dll ，这个问题是关于 别名的 。
假设Test类的编程名称是TestNameSpace.Test
[ProgId("TestNamespace.Test")] public class Test ...
现在，假设一个C＃解决方案已被密封并编译成*.dll ，我在Excel的VBE中引用它。 注意：此时我无法修改程序名称，就好像*.dll不是我编写的那样。
这是在VBA ：而不是像这样声明一个变量：
Dim myTest As TestNameSpace.Test Set myTest = new TestNameSpace.Test
我更喜欢称之为（仍在VBE中）
Dim myTest As Test Set myText = new Test
在C＃中你通常会说
using newNameForTest = TestNamespace.Test; newNameForTest myTest = new NewNameForTest;
注意：假设VBA项目中没有命名空间冲突
问题： 在VBA中using或VB.NET imports别名是否有相同的调用？
有趣的问题（不断使用它们但从未考虑过它们的确切含义）。 Imports语句的定义 （ using相同）非常清楚：它唯一的function是通过删除相应的名称空间来缩短引用。 因此，要问的第一个问题是：VBA有这样的东西（命名空间）吗？ 答案是否定的，因为你可以从多个来源阅读; 示例： 链接1 链接2
总之，在没有找到任何VBA语句的单一引用之后，做了类似于Imports / using事情，并且确认VBA不认为“结构”certificate了它们的使用（命名空间），我认为我可以说：不，VBA中没有这样的东西。
此外，你应该记住它不会有任何真正的适用性。 例如：在转换可能使用Imports的VB.NET代码时，例如：
Imports Microsoft.Office.Interop.Word ... Dim wdApp As Application
代码将完全更改，以便生成的字符串不会太长：
Dim wdApp As Word.Application ' Prefacing the library's display name.
我认为这是一个很好的图解原因，解释了为什么VBA不需要这样的东西：VB.NET解决了各种各样的现实，必须进行适当的分类（命名空间）; VBA占很少的情况，因此可以承担不执行如此系统化，长命名的分类。
————————–澄清
Imports / using只是名称缩短，也就是说，不是每次在Module / Class使用给定命名空间的对象时编写whatever.whatever2.whatever3，而是在开头添加Imports / using语句，基本上，意思是：“对于命名空间X的所有成员，只要忘记所有标题bla，bla”。
我并不是说你不能效仿这种行为; 只是强调在VB.NET中具有内置的短名称function是有意义的，其中名称可能变得非常长，但在VBA中却没有那么多。
答案是否定的：有一个内置的VBEfunction可识别添加到项目中的引用，并在运行时（VBE的运行时）创建别名，如果没有名称冲突
如果您的注册表中的名称冲突全部. 点将替换为_下划线。
» ProgId （程序化标识符）
在COM中，它仅用于后期绑定。 这是你打电话来创建一个新对象的方式
Dim myObj = CreateObject("TestNamespace.Test")
» EarlyBinding和LateBinding
在早期绑定中，您可以使用new关键字指定要创建的对象的类型。 您的对象名称应弹出VBA的intellisense。 它与ProgId无关。 要检索用于对象类型的实际命名空间 – 打开Object Explorer F2并在那里找到它
本文解释了早期绑定部分中名称的来源
使用相同的链接 何时使用后期绑定
对于MSDN Programmatic Identifiers部分，请参阅此内容