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

Question

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

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

Answer 1

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

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

» ProgId's   (Programmatic Identifiers)

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

Dim myObj = CreateObject("TestNamespace.Test")

» EarlyBinding and LateBinding

In early binding you specify the type of object you are creating by using the new keyword. 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 Explorer F2 and locate it there

This article explain where the names come from in Early Binding Section
use the same link for When to use late binding

for MSDN Programmatic Identifiers section please see this

Answer 2

Interesting question (constantly using them but never thought about their exact meaning). The definition of the Imports statement (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 1 Link 2

In summary, after not having found a single reference to any VBA statement doing something similar to Imports/using and 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.

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

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.

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

Imports/using is 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/using statement at the start which, basically, means: "for all the members of the namespace X, just forget about all the heading 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.