Ссылочные библиотеки VBA

В дополнение к этому ответу, который является пуленепробиваемым решением решить этот вид проблемы, но который довольно сложен для реализации, можно также написать некоторый код, который будет выполняться, когда приложение VBA запускается, проверяя 'ссылочный' набор объекта 'приложения'. Можно затем проверить (1) если требуемые файлы (dll, ocx, tlb) доступны на компьютере и (2) если ссылка может быть создана (application.references.addFromFile...).

Будьте осторожны: объектные объявления, которые могли бы быть 'ссылочным зависимым', таким как:

Dim cat as ADOX.catalog 

повысит ошибку компиляции, если ссылка не будет активна, когда соответствующий модуль 'компилируется'. Я затем советую Вам изолировать свою 'ссылочную процедуру проверки' в модуле запуска (эквивалентный 'автодолжностному лицу'), который имеет дело только с VBA и основными объектами приложения. Проверьте его со своими Справочными файлами (Пример: в Доступе ссылки по умолчанию, которые могут использоваться без внешних ссылок, являются VBA, Доступом и ДАО).

Править:

в случае, если внешние ссылки зависят от другого пакета программного обеспечения, и (1) не может быть распределен с файлом MSI или (2) может иметь несколько версий, я думаю, что 'references.addFromFile' является единственным решением, которое может применяться. Пример:

• У Вас есть клиентское приложение во время выполнения VBA/Access, которое должно обратиться к Word (msword.olb файл).
• Для лицензирования проблем Вы не можете свободно распределить этот файл со своим пакетом msi
• olb файл может быть или 'версией XP или более новой

Наше решение состоит в том, чтобы иметь 2 таблицы на клиентском файле Доступа. Каждый перечисляет все ссылки, которые должны быть проверены или добавлены во время запуска (Word будет одним из них), и другой перечисляет все возможные местоположения файла (зависящий, если у пользователя есть 'office11' версия или более новая), с одним ко многим отношениям между этими 2 таблицами.

Так, лучшая стратегия могла быть соединением между пакетами msi и управлением через код:

• msi является большим для распределения или других файлов независимого dll, которые полностью 'встраиваются' в Ваше приложение, такое как элементы управления ActiveX (как средства управления сканерами, отчет или средства просмотра файла, и т.д.)
• код является лучшим решением, где Ваше приложение должно будет общаться с другими приложениями (слово, Excel, перспектива, и т.д.), который может существовать в различных версиях на машинах Вашего пользователя.

Вместо того, чтобы иметь документы выставляют функциональность, делают это дополнением для Office (пакет, или отдельные приложения, Ваш выбор). Таким образом, Вы не должны иметь дело со ссылками.

Затем просто распределите пакет установки с дополнением, которое регистрирует компоненты и регистрирует дополнения в соответствующих приложениях Office.

VB6 мог бы быть хорошей идеей здесь, учитывая он - подобие VBA.

По большей части позднее связывание решит проблемы со ссылками в VBA, если у Вас не будет некоторых необычных ссылок. Большинство проблем вызывается различиями в версиях библиотеки, которые могут быть преодолены с поздним связыванием. С VBA часто рекомендуется разработать с ранним связыванием, но выпуском с поздним связыванием. Основной недостаток позднего связывания изменяет встроенные константы на значения (скорость больше не является проблемой, которой это раньше было.)

Так:

Dim fs As Object 'Instead of FileSystemObject '
Dim xl As Object 'Instead of Excel.Application '

Set fs=CreateObject("Scripting.FileSystemObject")
Set xl=CreateObject("Excel.Application")

'Value instead of built-in constant '
ForReading=2
Set f = fs.OpenTextFile("c:\testfile.txt", ForReading)

Если у Вас есть ссылки, от которых Ваше приложение зависит, который Вы знаете, не будут на целевых ПК, то я настоятельно рекомендовал бы исследовать некоторую технологию установщика.

Используя установщик необходимо смочь установить макрос, и установить и зарегистрировать все соответствующие ссылки / библиотеки.

Обычно существует два аромата на окнах, основанной на Windows Installer технологии и основанной на сценарии технологии.

Мы используем InstallShield для всего нашего развертывания, хотя существует несколько опций для Вас использовать (существует несколько обсуждений Переполнения стека).

Используя технологию установщика Windows, можно создать файлы установки MSI, которые Вы затем можете развернуть автоматически Групповую политику использования.