2

Often my exe's have dll dependencies that I package with an installer like nsis or inno. This makes sense for large programs but is overkill for small scripts.

Is there an alternative way to bundle dependencies, so that the user can just execute a single exe and not require a directory of dll's in the PATH?


EDIT

I am hoping for a solution that won't depend on the type of dll's, and will work for other kinds of dependencies too.

Here are some potential options:

Does anyone have experience with a tool like this?

hoju
  • 28,392
  • 37
  • 134
  • 178
  • Most experienced developers would advise you against using these tools and instead to the conventional thing of installing the EXE and DLL to the same directory. You appear not to want to follow this advice. Since you are dead set on using one of these tools why don't you just do so? – David Heffernan Apr 30 '11 at 04:08
  • 1
    I always have in the past, but currently I distribute a lot of small scripts and the clients don't like the folder of dependencies. – hoju May 01 '11 at 23:16

5 Answers5

2

You could statically link the executable.

Delan Azabani
  • 79,602
  • 28
  • 170
  • 210
2

Ok, you didn't like either of my other two ideas... so here goes...

You ship and give your customers a "stub EXE". The stub EXE doesn't depend on anything else and just contains a ZIP file (or setup package or similar) as a resource in your stub EXE. The zip file embedded in the stub EXE just contains the actual program EXE and all its dependent DLLs. When the stub EXE runs, it just unpacks the ZIP file to a TEMP sub-directory and launches the application EXE.

You could optimize it such that if the app has already been installed in %TEMP%, then you skip the unpacking step and just launch the application EXE already present.

Personally, I wouldn't go this route. Just give the user an installer if the EXE has dependencies. But you know your users and customers better than I do.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • Wouldn't it be easier to just set up a click once application to handle all of this? – pjwilliams Apr 30 '11 at 23:34
  • It might be even possible to load all required files right from that stub exe, however, it would be harder to implement than merely extract all the required files to a temp directory and start the main application from there. – Alexey Ivanov May 02 '11 at 10:10
  • I agree, that's why I suggested in my final line above "Just give the user an installer...". – selbie May 03 '11 at 03:23
1

One alternative is to install the DLL's in the GAC.

pjwilliams
  • 300
  • 2
  • 10
1

You didn't mention what the DLL dependencies are. Just straight up DLLs with a stub lib? Dynamically loaded via LoadLibrary? COM? Registration required? Is any of this .NET?

Several options to consider.

  1. Put the all the required DLLs in the same directory as the EXE (so you don't have to muck with the PATH variable). Installation is just a "copy *.*" or just allowed to run from a file share. (YMMV if there is .NET code - as that has security restriction when run from a remote file share).

  2. Statically link the EXE with the C-Runtime instead of the dynamic option (so you don't have to redist the MSVCRT on machines that don't already have it installed).

I have some crazier ideas if the above 2 items don't suffice. Let me know.

selbie
  • 100,020
  • 15
  • 103
  • 173
0

Apparently there exists software that can convert a DLL to a LIB, so that you can link against it statically, but that might be overkill in this case.

hammar
  • 138,522
  • 17
  • 304
  • 385