how to bundle dependencies in exe

问题:

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:

• http://www.adontec.com/index.htm?GO=/runtimepacker_e.htm
• http://boxedapp.com/
• http://www.filetransit.com/view.php?id=16640

Does anyone have experience with a tool like this?

回答1:

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.

回答2:

You could statically link the executable.

回答3:

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

回答4:

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.

回答5:

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.