VBA 相当于 C# using 或 VB.NET 导入/创建别名

VBA equivalent to C# using or VB.NET imports / creating aliases

提问by

Base Reference: Ten Code Conversions for VBA, Visual Basic .NET, and C#

基础参考：VBA、Visual Basic .NET 和 C# 的十种代码转换

Note: I have already created and imported a *.dll, this question is aboutaliases.

注意：我已经创建并导入了一个*.dll，这个问题是关于aliases 的。

Let's say the programmatic name of a Testclass is TestNameSpace.Test

假设一个Test类的程序名称是TestNameSpace.Test

[ProgId("TestNamespace.Test")]
public class Test ...

Now, say a C# solution has been sealed and compiled into a *.dlland I'm referencing it in a Excel's VBE. Note: at this point I cannot modify the programmatic name as if the *.dllwasn't written by me.

现在，假设一个 C# 解决方案已被密封并编译成一个*.dll，我在 Excel 的 VBE 中引用它。注意：此时我无法修改程序名称，就好像它*.dll不是我写的一样。

This is in VBA: Instead of declaring a variable like this:

这是在VBA：而不是像这样声明一个变量：

Dim myTest As TestNameSpace.Test
Set myTest = new TestNameSpace.Test

I'd prefer to call it (still in VBE)

我更愿意称之为（仍在 VBE 中）

Dim myTest As Test
Set myText = new Test

In C# you would normally say

在 C# 中，你通常会说

using newNameForTest = TestNamespace.Test;
newNameForTest myTest = new NewNameForTest;

Note: Assume there are no namespace conflictsin the VBAproject

注意：假设有没有命名空间冲突的VBA项目

Question: is there an equivalent call in VBAto C#usingor VB.NETimportsaliases?

问：是否有一个等价的调用VBA来C#using或VB.NETimports别名？

采纳答案by varocarbas

The answer is no: there is a built-in VBE feature that recognizes the references added to a project and creates aliases at run-time(VBE's runtime) if there are no name collisions

答案是否定的：如果没有名称冲突，有一个内置的 VBE 功能可以识别添加到项目中的引用并在运行时（VBE 的运行时）创建别名

In case of name conflicts in your registry all .dots will be replaces with _underscores.

如果您的注册表中出现名称冲突，所有.点都将替换为_下划线。

» ProgId's   (Programmatic Identifiers)

»ProgId的   （程序标识符）

In COM, it is only used in late-binding. It's how you make a call to create a new object

在 COM 中，它仅用于后期绑定。这就是您调用以创建新对象的方式

Dim myObj = CreateObject("TestNamespace.Test")

» EarlyBindingand LateBinding

»EarlyBinding和LateBinding

In early binding you specify the type of object you are creating by using the newkeyword. The name of you object should pop up with the VBA's intellisense. It has nothing to do with the ProgId. To retrieve the actual namespace used for your object type - open Object ExplorerF2and locate it there

在早期绑定中，您可以使用new关键字指定正在创建的对象类型。您对象的名称应该与 VBA 的智能感知一起弹出。它与ProgId. 要检索用于您的对象类型的实际命名空间 - 打开Object ExplorerF2并在那里找到它

This articleexplain where the names come from in Early Binding Section
use the same linkfor When to use late binding

这篇文章解释了早期绑定部分中名称的来源对何时使用后期绑定
使用相同的链接

for MSDN Programmatic Identifiers section please see this

对于 MSDN Programmatic Identifiers 部分，请参阅此

回答by varocarbas

Interesting question (constantly using them but never thought about their exact meaning). The definition of the Importsstatement(same for using) is pretty clear: its only function is shortening the references by removing the corresponding namespaces. Thus, the first question to ask is: has VBA such a thing (namespaces) at all? And the answer is no, as you can read from multiple sources; examples: Link 1Link 2

有趣的问题（不断使用它们但从未想过它们的确切含义）。语句的定义Imports（与 相同using）非常清楚：它唯一的功能是通过删除相应的命名空间来缩短引用。因此，要问的第一个问题是：VBA 有这样的东西（命名空间）吗？答案是否定的，因为您可以从多个来源阅读；示例：链接 1链接 2

In summary, after not having found a single reference to any VBA statement doing something similar to Imports/usingand having confirmed that VBA does not consider the "structure" justifying their use (namespaces), I think that I am in a position to say: no, there is not such a thing in VBA.

总而言之，在没有找到对任何 VBA 语句的单一引用执行类似于Imports/using并确认 VBA 不考虑证明其使用（命名空间）合理的“结构”之后，我认为我可以说：不，VBA中没有这样的东西。

Additionally you should bear in mind that it wouldn't have any real applicability. For example: when converting a VB.NET code where Importsmight be used, like:

此外，您应该记住，它没有任何实际适用性。例如：在转换Imports可能使用的 VB.NET 代码时，例如：

Imports Microsoft.Office.Interop.Word
...
Dim wdApp As Application

the code would be changed completely, such that the resulting string will not be so long:

代码将被完全更改，这样生成的字符串就不会那么长：

Dim wdApp As Word.Application ' Prefacing the library's display name.

I think that this is a good graphical reason explaining why VBA does not need to have this kind of things: VB.NET accounts for a wide variety of realities which have to be properly classified (namespaces); VBA accounts for a much smaller number of situations and thus can afford to not perform a so systematic, long-named classification.

我认为这是一个很好的图形原因，解释了为什么 VBA 不需要这种东西：VB.NET 考虑了必须正确分类（命名空间）的各种现实；VBA 考虑的情况要少得多，因此可以不执行如此系统的、长命名的分类。

-------------------------- CLARIFICATION

-------------------------- 澄清

Imports/usingis a mere name shortening, that is, instead of writing whatever.whatever2.whatever3 every time you use an object of the given namespace in a Module/ Class, you add an Imports/usingstatement at the start which, basically, means: "for all the members of the namespace X, just forget about all the heading bla, bla".

Imports/using只是名称的缩写，也就是说，不是每次在Module/ 中使用给定命名空间的对象时都写whatever2.whatever3，而是在开头Class添加一个Imports/using语句，这基本上意味着：“对于所有命名空间 X 的成员，只需忘记所有标题 bla, bla”。

I am not saying that you cannot emulate this kind of behaviour; just highlighting that having an in-built functionality to short names makes sense in VB.NET, where the names can become really long, but not so much in VBA.

我并不是说你不能模仿这种行为；只是强调在 VB.NET 中具有短名称的内置功能是有意义的，其中名称可以变得非常长，但在 VBA 中不会那么长。