Использование пользовательских DLL с Inno-Setup

У меня проблемы с загрузкой Inno-Setup моей DLL.
Я просмотрел похожие посты, но ни одно из предложенных в них решений, похоже, не помогло. В частности, этот сообщение подошло очень близко, но, похоже, не совсем та же проблема.

Мой установщик прекрасно работает на моей тестовой системе. Моя DLL написана на C ++, используя VS 2010. Есть файл DEF. Я успешно использовал VS-отладчик, чтобы присоединиться к потоку установщика и просмотреть мой код. Все хорошо. Релиз версия работает просто отлично в моей тестовой системе без отладчиков. Программа установки вызывает мою DLL, и она работает.

Затем я беру свой установщик в другую, нетронутую систему, чтобы опробовать его. Каждый раз, когда я запускаю установщик, он запускается с обычной подсказкой UAC: «Вы хотите, чтобы следующая программа от неизвестного издателя вносила изменения в этот компьютер?» И я говорю «Да». Затем я получаю звуковой сигнал и предупреждение, которое говорит:

Runtime Error (at -1:0):
Cannot import
dll:<utf8>C:\Users\Logicrat\AppData\Local\Temp\is-4E245\MyDLL.dll

В моем сценарии установки у меня есть

[Files]
Source: "MyDLL.dll"; DestDir: "{app}"; Flags : dontcopy

а также

function MyFunc(hWnd: Integer; lpText, lpCaption: AnsiString; uType: Cardinal): Integer;
external 'MyFunc@files:MyDLL.dll stdcall setuponly';

Согласно документации Inno, dontcopy Флаг является подходящим, если DLL не нужна для удаления, а это не так.

Я подозреваю, что проблема заключается в том, чтобы точно указать, где должна быть DLL, так как мой скрипт требует, чтобы она была в {app} каталог, но сообщение об ошибке относится к временному каталогу. Я пробовал несколько вариантов сценария, все с одинаковыми результатами.

И моя система разработки / тестирования, и моя первоначальная целевая система работают под управлением Windows 7 (32-разрядная версия). Я стучал об этом в течение нескольких недель без видимого прогресса. Любые предложения будут приветствоваться.

1

Решение

Проблема решена благодаря предложению TLama о проверке зависимостей. Когда я изначально создал новый проект для моей DLL в MS Visual Studio 2010, я выбрал опцию «Использовать MFC в общей библиотеке». Это оказалось источником проблемы, так как сама библиотека зависела от mfc100u.dll а также msvcr100.dll, которых не было в целевой системе, которую я использовал для тестирования моего установщика. Я исправил это, изменив настройку проекта на «Использовать MFC в статической библиотеке». Это сделало библиотеку DLL больше, но она также заработала. Затем, после того как я сначала перестроил DLL, а затем перестроил установщик, который ее использовал, все было хорошо.

Возможно, было бы неплохо, если бы сообщение об ошибке, которое я получил в первый раз, назвало искомую DLL вместо DLL, которая пыталась вызвать отсутствующую.

1

Другие решения


По вопросам рекламы [email protected]