在程序启动时获取 BPL 版本
当程序启动时，是否可以检查客户端计算机上安装的 BPL 版本（即 Rtl70.BPL、Indy70.bpl 等）？
我遇到过一些程序崩溃的情况，因为计算机上的 BPL 与构建计算机上的 BPL 不同。
如果我必须在每次更新时将使用的每个 BPL 添加到安装程序中，我认为这将破坏使用它们的要点之一。
Delphi 7，如果有影响的话
Just a follow up on the issue i had.
The rtl70.bpl file was only slightly different between the build computer and the clients.
客户端计算机：7.0.4.453 760 KB（778,240 字节）2002 年 8 月 20 日星期二下午 4:40:26
构建计算机：7.0.4.453 760 KB（778,240 字节）2002 年 8 月 9 号星期五，11:30:00 PM
我使用的更新程序忽略了它们，因为它们是相同的（内部版本号没有变化），但是当我手动删除并复制文件时，一切似乎都正常。
Is it possible to check what version of BPL (ie Rtl70.BPL, Indy70.bpl etc) are installed on a clients computer when the program starts?
I have had some programs crash because the BPL on there computer is different to the ones on the build machine.
If i have to add each BPL used into the installer on each update, i think it will defeat one of the points on using them.
Delphi 7, if it makes a difference
Just a follow up on the issue i had.
The rtl70.bpl file was only slightly different between the build computer and the clients.
Clients Computer: 7.0.4.453 760 KB (778,240 bytes) Tuesday, 20 August 2002, 4:40:26 PM
Build computer: 7.0.4.453 760 KB (778,240 bytes) Friday, 9 August 2002, 11:30:00 PM
The updater i was using ignored them as being the same (no change in build number), but when i manually deleted and copied the files every thing seemed to work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您必须将 BPL（RTL70.bpl、INDY.BPL...）的副本（开发）安装到安装应用程序的同一目录中。 您的应用程序首先搜索同一目录中的 BPL，然后搜索路径内的目录。
缺点是您的系统可以拥有同一 BPL 的多个副本，优点是您不会因同一文件的不同版本而出现问题。
问候。
PD：请原谅我的英语不好。
You must install your copy (develop) of BPL's (RTL70.bpl, INDY.BPL,...) into the same directory that you install the application. Your application search first the BPL's at the same directory and after search at directories inside the path.
The negative point is that your system will can have several copies of the same BPL, the positive point is that you will not have problems with differents versions of the same file.
Regards.
P.D: Excuse-me for my bad english.
您无法通过使用这些 bpls 的可执行文件来执行此操作，但您可以使用一个小型启动程序来检查 bpls，然后调用主可执行文件。
You cannot do that from an executable that uses these bpls, but you could have a small startup-program that checks the bpls and then calls the main executable.
有时Delphi会自动添加行的形式：
{$R ' *.res'}
到项目或包的文件。
注释（//）该行并再次编译。
Sometimes Delphi adds of automatic form the line:
{$R ' *.res'}
to the files of project or packages.
Comment (//) that line and to compile again.
很不幸的是，不行。 如果崩溃是由于缺少应用程序所需的 .bpl 文件的导入造成的，则无法（除了重写 Delphi RTL 和链接器本身）从崩溃的可执行文件本身检查这些包。 PatrickvL 的解决方案可能最适合您的情况。
Neftalí 的解决方案可能是一种选择 - 当然，代价是打包 RTL、复制大量文件，并失去一开始就拥有软件包的一个要点。 但是，如果您使用私有 DLL（即，如果您将 DLL 复制到私有二进制文件目录中），那么您还应该创建一个与可执行文件同名的空文件，但附加扩展名 .local 到它，即对于notepad.exe，您将创建一个notepad.exe.local。 有关更多详细信息，请参阅 Raymond Chen 有关 DLL 重定向的文章。
Unfortunately, no. If the crash is due to missing imports from the .bpl files required by your application, there is no way (short of rewriting the Delphi RTL and linker themselves) to check for those packages from within the crashing executable itself. PatrickvL's solution is probably the best for your situation.
Neftalí's solution might be an option - of course, at the cost of packaging the RTL, duplicating a lot of files, and losing one of the points of having packages in the first place. However, if you're using private DLLs (i.e., if you copy the DLLs in your private binaries directory) then you should also create an empty file with the same name as your executable but appending the extension .local to it, i.e. for notepad.exe you'd create a notepad.exe.local. See Raymond Chen's article on DLL redirection for more details.
如果您的程序崩溃，可能是因为它无法加载与其动态链接的库。 （正如您所说，当系统在搜索路径中的任何位置找不到所需库的副本时，就会发生这种情况）。
问题是，这种情况发生在应用程序启动时，Windows 操作系统通过名为 MapAndLoad（另请阅读此）。 这个 API 是在你的应用程序启动之前调用的，所以我看不出有什么方法可以拦截它。
我可以给出的一个建议是使用启动器（必须静态链接，以防止根本没有/没有/库时出现问题）。
该启动器可以检查您的实际应用程序，查看它需要导入什么，检查您的环境并向用户显示一个不错的故障/故障排除建议对话框。
If your program crashes, it's probably because it can't load the library it's dynamically linked with. (As you where saying, this happens when the system can't find a copy of the needed libaries anywhere in the search path).
The problem is, that this happens at startup of an application, which the Windows OS does via an API called MapAndLoad (also read this). This API is called before your application is even started, so I see no way to intercept this.
One suggestion I could give, would be to use a launcher (which has to be statically linked, to prevent problems for when there are /no/ libraries at all).
This launcher could inspect your actual application, see what imports it needs, checks your environment and display a nice failure/troubleshooting suggestion dialog to the user.