Using custom DLL with Inno-Setup

Question

I am having trouble getting Inno-Setup to load my DLL. I have looked at similar posts, but none of the solutions offered in those seem to help.In particular, this post came very close, but does not seem to be quite the same issue.

My installer runs just fine on my test system. My DLL is written in C++, using VS 2010. There is a DEF file. I have been successful using the VS debugger to attach to the installer's thread and step through my code. Everything is good. The release version runs just fine on my test system with no debuggers involved. Setup calls my DLL and it works.

Then I take my installer to a different, pristine system to try it out. Every time, when I launch the installer, it starts off with the usual UAC prompt: "Do you want to allow the following program from an unknown publisher to make changes to this computer?" And I say "Yes." Then I get a beep and an alert that says:

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

In my setup script I have

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

and

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

According to the Inno documentation, the dontcopy flag is appropriate if the DLL is not needed for uninstall, which it is not.

I suspect the problem lies in designating exactly where the DLL is supposed to be, as I my script calls for it to be in the {app} directory, yet the error message refers to a temp directory. I've tried a number of variations of the script, all with the same results.

Both my development/test system and my pristine target system are Windows 7 (32-bit). I have been banging on this for weeks with no visible progress. Any suggestions will be most welcome.

Answer 1

Problem solved, thanks to the suggestion by TLama about checking dependencies. When I had initially created the new project for my DLL in MS Visual Studio 2010, I had selected the option to "Use MFC in a shared library." That turned out to be the source of the problem, as the DLL itself was then dependent on mfc100u.dll and msvcr100.dll, which were not present on the target system I used to test my installer. I fixed it by changing the project preference to "Use MFC in a static library." That made the DLL larger, but it also made it work. Then, after I first rebuilt the DLL and then rebuilt the installer that used it, everything was fine.

It might have been nice if the error message I got the first time around named the DLL it was looking for instead of the DLL that tried to call the missing one.