Delphi XE2:EResNotFound异常"Re​​source"< mainform>找不到"在某些目标机器上引发，但在其他机器上不引发 [英] Delphi XE2: EResNotFound exception "Resource "<mainform>" not found" raised on some target machines but not on others

问题描述

过去两天来，我一直对此表示怀疑，似乎并没有取得任何进展...

I've been banging my head against this for the past two days and can't seem to make any progress...

从一瞬间到下一瞬间，Delphi XE2将不再正确地编译我的项目之一.也就是说，它实际上没有错误地进行编译，但是在运行时，我得到了本质上主要的表单"(在这种情况下，它实际上是一个数据模块)找不到资源的错误.我已经从源代码控制恢复到项目的较旧版本，我知道该源代码肯定可以正常运行，但无济于事.从看来，这似乎一定是在Delphi/IDE本身内部而不是项目源代码中.但是，我也无法通过简单的测试项目或任何其他实际项目来重现此问题……仅在此项目中会发生.

Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.

另一个奇怪的事情是，当我用XN Resource Explorer查看生成的二进制文件时，一切看起来都应该像这样:错误消息中提到的表单资源实际上在那里并且完好无损...

Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...

在某个时候，我怀疑这可能是由于我在IDE中安装的一位专家(例如Uwe的平台和OI专家以及VersionInsightPlus，Andreas的IDEFixPack和DDevExtensions，GExperts)中的错误引起的，即使在禁用所有功能之后这些问题仍然存在.

At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.

不幸的是，由于我已经工作了一段时间，而无法实际运行二进制文件，因此无法准确地跟踪何时开始发生这种情况，无法修复x64目标的编译器警告和错误，无法为更新的第三方调整构建事件工具(本地化和许可证保护)之类的东西...

Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...

有没有其他人见过这样的事情?有关如何确定这一点的更多想法?

Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?

有关该项目的更多详细信息:

Some more details about the project:

• 这是使用Add-In-Express框架(即COM-DLL)构建的Outlook加载项.
• 主要形式"是 TDataModule 的后代-我们还将自己的祖先类插入到层次结构中，即"addin模块"不是直接继承自 TadxCOMAddInModule -当使用资源查看器检查时，自定义祖先表单的资源在输出二进制文件中也似乎存在并且完整无缺.
• 没有针对Win32和Win64平台的运行时程序包.

• It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
• The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
• Built without runtime packages for the Win32 and Win64 platforms.

如果您认为我错过了任何其他可能相关的细节，请告诉我.

Let me know if you think I missed to mention any other potentially relevant details.

更新:现在，我已将有问题的源转移到另一台计算机上.有趣的是，我在那里编译的DLL没有出现问题-在那台机器上……当我将其转移回原始计算机并尝试调用它时，错误又回来了(强调这一点:这是确切的相同的DLL在一台机器上产生 EResNotFound ，但在另一台机器上没有，当然，一旦我发现了这一点，我还进行了反向测试，瞧瞧，在原始机器上编译的DLL可以在没有在另一台机器上的错误...看来这可能根本不是Delphi的问题...但是那又是什么呢?

Update: I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine... Seems this might not be a Delphi problem after all... but what is it then?

两台机器之间的区别:

• 机器1(一个是发生问题的机器):Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
• 机器2:带有Delphi XE2 Update 3的Windows 7 Professional德语32位

在第三台与第一台机器几乎相同的机器上，除了没有Delphi之外，两台机器产生的DLL都可以正常工作.

On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.

推荐答案

更新:似乎我太快了，得出结论.显然，Sisulizer解决方案还应该执行对主资源块的回退.我现在已将此问题带到产品论坛，解决后将返回此处.

Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.

好吧，谜底终于解决了:

Alright, mystery solved at last:

我已关闭 Sisulizer 中的复制所有资源"选项，以减小尺寸产生的资源DLL的一部分，然后就忘记了...

I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...

我还没有完全意识到标准的Delphi资源DLL方法对本地化的影响，而Sisulizer会在该问题上背负"-尤其是这是一项全有或全无的交易:我们以前的翻译解决方案实现了一种后备机制，该机制将而是从主机二进制文件中读取在外部资源DLL中找不到的任何资源.Sisulizer似乎不是这种情况-至少不是开箱即用...因此，就应用程序而言，本地化资源DLL中未包含的任何资源都不存在.
我也没有意识到，仅存在一个与主二进制文件具有相同基本名称的文件，并且存在与当前系统的默认语言环境匹配的扩展名(例如 .EN 或 .DE )会自动导致VCL加载它...

I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...

没有出现错误的计算机要么仍然具有较旧的，较大的(=完整的)资源DLL，要么根本没有资源DLL.

The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.

这篇关于Delphi XE2:EResNotFound异常"Re​​source"< mainform>找不到"在某些目标机器上引发，但在其他机器上不引发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！