过去两天我一直在反对这一点，似乎无法取得任何进展......
从一个时刻到下一个时刻，Delphi XE2将无法正确编译我的一个项目。也就是说，它实际上编译没有错误，但在运行时我得到资源未找到错误的本质上是主要的“形式”（在这种情况下它实际上是一个数据模块）。我已经从源代码控制恢复到该项目的旧版本，我知道这些版本肯定正常，但无济于事。从它来看，似乎它必须是Delphi / IDE本身而不是项目源中的东西。但是，我也无法通过一个简单的测试项目或任何其他现实生活中的项目来重现这个问题......只会发生在这个问题上。
另一件奇怪的事情是，当我使用XN Resource Explorer查看生成的二进制文件时，一切看起来应该是这样的：错误消息中提到的表单资源实际上存在且完好无损......
在某些时候，我怀疑这可能是由我在IDE中安装的一位专家（例如Uwe的平台和OI专家和VersionInsightPlus，Andreas的IDEFixPack和DDevExtensions，GExperts）中的一个错误导致的，但即使在禁用所有这些问题依然存在。
不幸的是，我无法准确追踪这种情况何时开始发生，因为我已经工作了一段时间而没有实际运行二进制文件，修复x64-target的编译器警告和错误，为更新的第三方调整构建事件工具（本地化和许可证保护）等等......
还有其他人见过这样的事吗？关于如何确定这一点的更多想法？
有关该项目的更多细节：
TDataModule - 后代 - 我们还将自己的祖先类插入到层次结构中，即“addin模块”不直接继承自TadxCOMAddInModule - 资源在使用资源查看器检查时，自定义祖先表单在输出二进制文件中也显示为完整且完整。如果您认为我错过了提及任何其他可能相关的细节，请告诉我。
更新
我现在已将有问题的资源转移到另一台机器上。有趣的是，我在那里编译的DLL没有出现问题 - 在那台机器上......当我将它转移回原始机器并且我试图调用它时，错误又回来了（强调这一点：这是确切的同一个DLL在一台机器上产生EResNotFound但在另一台机器上没有产生。当然，一旦我发现了这个，我也进行了反向测试，并且看，在原始机器上编译的DLL在没有错误的情况下运行其他机器......
看来这毕竟不是德尔福问题......但那又是什么呢？
两台机器之间的差异：
在第三台几乎与第一台机器完全相同的机器上，除了没有Delphi，两台机器生成的DLL都能完美运行。
答案 0 :(得分：1)
我在这里看到你的问题有点意外。 ：）
最近针对Delphi XE2的Update 4遇到了许多严重问题。虽然我们从未遇到或报告过“未找到资源”错误，但我认为此更新可能是其中一个原因。你安装好了吗？
我想到的另一件事是您用于Office控件（命令栏和功能区）的图像。可能他们以某种方式破坏了，运行时代码无法加载它们并报告此错误。
无论如何，正如您所理解的，这些只是我的猜测，如果您需要我们的办公室加载项帮助，请联系加载项快速支持服务，我们将尽力提供帮助。
答案 1 :(得分：0)
更新：似乎我有点太快了，得出结论。显然，Sisulizer解决方案也应该执行主资源块的回退。我现在已经将此问题发送到product forum，并且一旦解决就会在此报告。
好吧，神秘终于解决了：
我已关闭Sisulizer中的“复制所有资源”选项，试图减少生成的资源DLL的大小，然后忘记了它......
我还没有完全意识到标准的Delphi资源DLL方法对Sisulizer“搭载”的本地化的影响 - 特别是它是一个全有或全无的交易：我们以前的翻译解决方案实现了一个回退机制，从主机二进制文件读取外部资源DLL中找不到的任何资源。这似乎不是Sisulizer的情况 - 至少没有开箱即用......因此，就应用程序而言，本地资源DLL中未包含的任何资源都不存在。
我也没有意识到仅存在与主二进制文件具有相同基本名称的文件以及与当前系统的默认语言环境（例如.EN或.DE）匹配的扩展名将自动导致VCL加载它......
没有出现错误的计算机上仍然有较旧的，较大的（=完整的）资源DLL，或者根本没有资源DLL。