3

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.

Community
  • 1
  • 1
Logicrat
  • 4,438
  • 16
  • 22
  • Check if your imported function name matches exactly (it is case sensitive) to the name of the exported function. The rest of your script seems to be correct. – TLama Jul 29 '14 at 19:13
  • @TLama Yes, it does match. I suspect that it would not run on my test system otherwise. I have tried variations of `__declspec(dllexport)` and `__stdcall` on the function declaration as well; it always works fine on my development machine, never on other machines. – Logicrat Jul 29 '14 at 19:19
  • Ah, sure it wouldn't run even on your machine. Well, you're suspecting that path, but it is correct. By that `files:MyDLL.dll` you're telling the scripting engine to extract the `MyDLL.dll` library from the `[Files]` section into the setup's temporary folder and load it from there, which seems to happen. It looks that you've started with [`this example`](https://github.com/jrsoftware/issrc/tree/master/Examples/MyDll/C), is that right ? Did it work for you (without any modification) ? – TLama Jul 29 '14 at 19:56
  • @TLama No, I hadn't seen that example before. I started by working with some of the sample .iss files that are installed along with Inno Setup, along with several of the Pascal script examples that are in Inno's documentation. I get the impression that Inno Setup is having trouble locating my DLL on the target system. I already have a copy of the DLL in the same folder where my Inno script lives on my development system, so that it can be included in the build. – Logicrat Jul 29 '14 at 19:59
  • 2
    Aren't you victim of some antivirus sandbox on that target system ? Because the `files:` prefix works for ages (and works the way I've described). Or isn't your library dependent on another one (which is missing in the setup) ? P.S. that error message is really broad; it occurs for many situations, so don't be sure it is just the listed library that cannot be found. – TLama Jul 29 '14 at 20:24
  • @TLama I'm going to check other dependencies, but the error message seems explicitly to target my DLL as opposed to something like MSVCRT. Just the same, it's a good idea and certainly worth checking. I don't think there is any antivirus on (and I hope that reasonable AV protection would not be a roadblock) but I will certainly check that as well. Thanks for the thoughts. – Logicrat Jul 29 '14 at 22:24
  • @TLama Your suggestion about dependencies has yielded fruit. I rebuilt my DLL and statically linked MFC instead of dynamically linking it. All of a sudden, my installer is working on my pristine target system. Many thanks. – Logicrat Jul 30 '14 at 19:58
  • You're welcome! Feel free to post your own answer to help others with the same problem. – TLama Jul 31 '14 at 01:00

1 Answers1

3

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.

Logicrat
  • 4,438
  • 16
  • 22
  • 1
    That error message is misleading and is thrown also for cases such as missing import function. But it's not Inno Setup's fault. That is given by the underlying Pascal Script scripting engine. – TLama Aug 01 '14 at 14:45
  • 1
    @TLama I'm glad you shared that; it will make future problems a little easier to diagnose and fix. – Logicrat Aug 01 '14 at 17:34