how to bundle dependencies in exe

Question

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 t

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

You could statically link the executable.

Answer 5

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.