如何在exe中捆绑依赖项

发布于 2024-11-04 04:43:27 字数 768 浏览 3 评论 0原文

我的 exe 通常具有 dll 依赖项,我使用 nsisinno。 这对于大型程序来说是有意义的,但对于小型脚本来说就太过分了。

是否有另一种方法来捆绑依赖项,以便用户可以只执行单个 exe 而不需要 PATH 中的 dll 目录?


编辑

我希望有一个不依赖于 dll 类型的解决方案,并且也适用于其他类型的依赖项。

以下是一些可能的选项:

有没有人有过像这样的工具?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

骷髅 2024-11-11 04:43:27

好吧,你不喜欢我的另外两个想法......所以这里......

你运送并给你的客户一个“存根 EXE”。存根 EXE 不依赖于任何其他内容,只包含一个 ZIP 文件(或安装包或类似文件)作为存根 EXE 中的资源。嵌入存根 EXE 中的 zip 文件仅包含实际的程序 EXE 及其所有依赖的 DLL。当存根 EXE 运行时,它只是将 ZIP 文件解压到 TEMP 子目录并启动应用程序 EXE。

您可以对其进行优化,如果应用程序已安装在 %TEMP% 中,则您可以跳过解压步骤并仅启动已存在的应用程序 EXE。

就我个人而言,我不会走这条路。如果 EXE 有依赖项,只需为用户提供一个安装程序即可。但你比我更了解你的用户和客户。

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.

∞梦里开花 2024-11-11 04:43:27

您可以静态链接可执行文件。

You could statically link the executable.

失而复得 2024-11-11 04:43:27

一种替代方法是在 GAC 中安装 DLL。

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

寻找一个思念的角度 2024-11-11 04:43:27

你没有提到DLL依赖项是什么。只是带有存根库的直接 DLL 吗?通过LoadLibrary动态加载? COM?需要注册吗?这是.NET 中的任何一个吗?

需要考虑的几个选项。

  1. 将所有必需的 DLL 放在与 EXE 相同的目录中(这样您就不必修改 PATH 变量)。安装只是“复制 *.*”或仅允许从文件共享运行。 (YMMV,如果有 .NET 代码 - 因为从远程文件共享运行时有安全限制)。

  2. 将 EXE 与 C 运行时静态链接,而不是动态选项(这样您就不必在尚未安装 MSVCRT 的计算机上重新发布 MSVCRT)。

如果以上两项还不够,我有一些更疯狂的想法。让我知道。

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.

伤痕我心 2024-11-11 04:43:27

显然存在软件可以将DLL转换为LIB,这样你就可以静态链接它,但在这种情况下这可能有点过头了。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文