Tools > References... Safe List

The standard advice when it comes to early and late binding is that you should develop using early binding but deploy using late binding.  

That's great advice when you are automating other Office applications, such as Word, Excel, Outlook, or PowerPoint.  If you use early binding with those COM libraries, the code will run fine on your development computer, but it will break if you deploy it to a user who has an older version of Office than the one on your development machine.

However, you sacrifice some real benefits when you use late binding rather than early binding.  

With early binding you get:

• Type safety
• IntelliSense
• Named constants
• Event handling
• Better performance (technically speaking; the effect is negligible in practical terms)

Type safety is particularly important, because it helps you turn runtime errors into cheaper, easier-to-fix compile errors.

Safe (No-Effort-Required) Early Binding References

Almost all early binding references can be safe.

However, some of them require you to copy and/or register files on your end-users' computers.  Depending on how you deploy your front-end application files, this can be a real pain.  For example, if you want to do a so-called "xcopy deployment"–where you simply copy your front-end Access file to somewhere your users can double-click on it to run it–you probably want to avoid including references that require registration on Windows via regsvr32.exe.

Sometimes you have references that only certain end users need.  This is a common situation with some third-party libraries.  In those cases, late binding is a better choice because the rest of the code will compile and execute even if the library is missing from the end user's computer.

The list below includes common references that are safe to include because they come pre-installed in all supported versions of Microsoft Windows.  

This list is clearly not exhaustive.  If you have a reference that you like to include in your Access (or Word or Excel or Outlook) applications that is built-in to Windows, let me know in the comments below and I will update the article.

Microsoft Scripting Runtime [Scripting]

The Microsoft Scripting Runtime includes the following commonly used features:

• FileSystemObject
• Dictionary

Microsoft VBScript Regular Expressions 5.5 [VBScript_RegExp_55]

This library includes the following classes that can be used to process regular expressions in VBA.  

• RegExp
• MatchCollection
• Match
• SubMatches

For usage examples, check out my article, Now You Have Two Problems, which includes definitions for the following custom functions:

• RegEx()
• RegExReplace()
• RegExExtract()

Microsoft Visual Basic for Applications Extensibility 5.3 [VBIDE]

This library is most often used during design time if you want to interact with the VBA development environment.

Microsoft XML, v6.0 [MSXML2]

Used to create and read XML documents.  Useful for importing data from other systems or to save/load configuration files.

If, for whatever reason, you would rather use late binding for this library, the relevant ProgIDs are available here:

Safe Early Binding References (With Important Caveats)

The DAO and ADO libraries have a lot of overlapping objects, including:

• Connection
• Recordset
• Parameter/Parameters
• Error/Errors
• Property/Properties

If you include both libraries in your project–which I have often done–you need to pay careful attention to the order the libraries are listed in the References dialog.  I always list the DAO library above the ADO library, as I tend to use the DAO library more often.

Another good habit to get into is to always explicitly include the library name when declaring objects from either library, but especially the overlapping objects from the list above. For example:

In the code above, the behavior of the MyCn variable will change if we update the Priority order in the References dialog.  Including the DAO. or ADODB. prefix makes the code more explicit and clarifies our intent.

A Note About Microsoft ADO Library Versions

There are seven different Microsoft ADO Library versions listed in Tools > References:

• Microsoft ActiveX Data Objects 6.1 Library: msado15.dll
• Microsoft ActiveX Data Objects 2.0 Library: msado20.tlb
• Microsoft ActiveX Data Objects 2.1 Library: msado21.tlb
• Microsoft ActiveX Data Objects 2.5 Library: msado25.tlb
• Microsoft ActiveX Data Objects 2.6 Library: msado26.tlb
• Microsoft ActiveX Data Objects 2.7 Library: msado27.tlb
• Microsoft ActiveX Data Objects 2.8 Library: msado28.tlb

The most current version, ADO 6.1, is compatible with Windows 7 and later (i.e., all currently supported Windows operating systems).  As of publication, this is the version you should use.

ADO version 6.0 (not listed above is it apparently cannot be installed on the same machine as version 6.1) is compatible with Windows Vista and later.

ADO versions 2.0 through 2.8 are compatible with Windows XP and later.

Reader Recommendations

Let me know in the comments below what libraries you commonly include in your applications, and I will update the lists above.

Additional reading

Early Binding vs. Late Binding: The Essential Guide for VBA Developers

The Absolute Minimum Every VBA Developer Absolutely, Positively Must Know About Early and Late Binding in COM (No Excuses!)

No Longer SetMike Wolfe

High Level Overview of COM

This whirlwind tour of the Component Object Model technology will jump start your journey of automating Excel from VBA in Access.

No Longer SetMike Wolfe

Five Ways to Turn Runtime Errors into Compile Errors in VBA

Compile errors are cheaper and easier to fix than runtime errors. Here are five ways to turn potential runtime errors into compile errors.

No Longer SetMike Wolfe