2016-09-21 2 views
3

У меня есть книга Excel, которая вызывает тестовую DLL, написанную на C++. Путь к DLL жестко закодирован в VBA. Единственными файлами, которые использует DLL, являются stdlib и iostream.VBA Calling C++ DLL - ошибка 48 (файл не найден)

На моей машине это работает. На нескольких других офисных машинах это работает. Тем не менее, в оставшейся части, когда я пытаюсь вызвать DLL через Excel, я получаю ошибку 48 - файл не найден.

Мое понимание - это ошибка 53, файл отсутствует; ошибка 48 есть недостающие зависимости. Я использовал ходул зависимостей и не обнаружил никаких проблем.

Однако я обнаружил, что если я установлю Visual Studio на машину, существует вероятность 90%, что после установки файл Excel/DLL отлично работает. На 10%, что он не работает, я перезапускаю и перезапускаю установку Visual Studio, выбираю «ремонт», а после завершения установки снова работает компиляция Excel/DLL. Таким образом, в основном установка Visual Studio позволяет DLL загружаться Excel. Если я удалю Visual Studio, DLL по-прежнему отлично работает.

Очевидно, это означает, что на этих машинах чего-то не хватает, но я понятия не имею, что - я пробовал отдельно устанавливать все части, которые отображаются под «программами», такими как большинство существующих .net framework, visual C++ re- дистрибутивы и т. д. ... и это не сработает. Единственное, что работает, - это установка самой Visual Studio. Я не уверен, как действовать с тех пор, как просить пользователей смонтировать ISO 5gig и установить среду разработчика, на самом деле не идеальна.


Ах-ха, я нашел проблему. Оказывается, для этого требуется 2 DLL-файла - msvcr120.dll и msvc120.dll. У меня были эти 2 файла в моей папке System32, но не в моей папке SysWOW64. Как только я заполнил эту папку, DLL начали работать.

Я нашел много потоков в google с такой же проблемой, но не ответил, поэтому, если вы столкнетесь с той же проблемой, я бы предложил использовать хост зависимостей и убедиться, что библиотеки DLL в обеих системных папках будут в безопасности (хотя Я подозреваю, что System32 требуется только для 64-битной DLL и SysWOW64 для 32-битных DLL-файлов).

ответ

1

Скорее всего, ваша DLL зависит от распространенных распространяемых на C++. В зависимости от версии VC++, которую вы использовали для разработки вашей DLL, вы должны установить соответствующую версию распространяемых на VC++ перераспределителей на целевой машине.

В случае VS 2015 вы можете найти VC++ распространяемые здесь: https://www.microsoft.com/en-us/download/details.aspx?id=48145

0

Используйте утилиту Monitor SysInternals процесса для контроля доступа DLL и искать ошибки. Пример приведен в этом other answer. Смотрите процесс Excel и операцию CreateFile.

0

А-ха, я нашел проблему. Оказывается, для этого требуется 2 DLL-файла - msvcr120.dll и msvc120.dll. У меня были эти 2 файла в моей папке System32, но не в моей папке SysWOW64. Как только я заполнил эту папку, DLL начали работать.

Я нашел много потоков в google с такой же проблемой, но не ответил, поэтому, если вы столкнетесь с той же проблемой, я бы предложил использовать хост зависимостей и убедиться, что библиотеки DLL в обеих системных папках будут в безопасности (хотя Я подозреваю, что System32 требуется только для 64-битной DLL и SysWOW64 для 32-битных DLL-файлов).

0

Ошибка 48 также может быть возвращена, когда dll не соответствует битности вызывающей программы. Итак, если вы используете Windows VBA Excel с 64-разрядной версией Excel, например, вы хотите, чтобы DLL была скомпилирована как 64-битный двоичный файл.

Примечание: это отличается от ошибки 53, которая действительно означает, что DLL не найдена ни в каких дорожках.

Смежные вопросы