调用 DLL 时 Excel VBA 错误“尝试加载格式不正确的程序”

发布于 2024-11-26 19:35:57 字数 885 浏览 1 评论 0原文

我有一个 Excel 文件,它在 auto_open VBA 宏中调用 .net DLL(称为“MyDLL”)。 当执行到下面的第二行时,出现以下错误:

--VBA Code--

If objSensitivity Is Nothing Then

Set objSensitivity = CreateObject("MyDLL.Calculations") '<<Crashes here

--Error--

发生错误:-2147024885 自动化错误 尝试加载格式不正确的程序。

我的系统是:

  • Windows 7 64 位 PC。
  • 它安装了 Excel 2003、2007 和 2010 (x86)
  • 它为 x86 和 x64 安装了 .Net Framework 1.1、2.0、3.0、3.5 和 4.0
  • 它具有所有最新的 Windows 更新。

其他说明:

  • 我知道 DLL 是在 VB 中的 VS2005 中创建的,目标 CPU 设置为“AnyCPU”,
  • 如果我更改“X86”的目标 CPU 设置,则没有任何区别 - 错误仍然发生。
  • 最近,由于硬盘故障,我不得不重建我的电脑,在此之前它运行良好。所以我不知道发生了什么导致它现在不起作用。
  • 这个问题出现在我打开文件的所有版本的 Excel 中。

因为我知道它在重建之前运行良好,而且我知道它适用于在 Windows 7 64 位上运行它的其他用户,所以我只能假设它是其他问题特定于我的 PC,而不是实际的 DLL。

有人可以帮忙吗?

I have an Excel file that calls a .net DLL (called "MyDLL") in the auto_open VBA macro.
When it gets to the 2nd line below, the error below occurs:

--VBA Code--

If objSensitivity Is Nothing Then

Set objSensitivity = CreateObject("MyDLL.Calculations") '<<Crashes here

--Error--

An Error has occured: -2147024885
Automation error
An attempt was made to load a program with an incorrect format.

My system is:

  • A Windows 7 64-bit PC.
  • It has Excel 2003, 2007 and 2010 installed (x86)
  • It has .Net Framework 1.1, 2.0, 3.0, 3.5 and 4.0 installed for both x86 and x64
  • It has all the latest windows updates.

Other notes:

  • I know that the DLL was created in VS2005 in VB with a Target CPU setting of 'AnyCPU'
  • It makes no difference if i change the Target CPU setting of 'X86' - the error still occurs.
  • I recently had to rebuild my PC due to a hard drive failure, and before that it worked fine. So i dont know what has happened for it to not work now.
  • The issue occurs in all versons of Excel i open the file in.

Since i know that it worked fine previous to my rebuild, and i know it works for other users running it on Windows 7 64 bit, i can only assume it is something else specific to my PC, and not the actual DLL.

Can anyone help?

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

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

发布评论

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

评论(4

最美不过初阳 2024-12-03 19:35:57

我解决了这个问题。

我对所有版本的 Office 进行了修复安装,因为我怀疑它是有错误的 Microsoft Interop DLL,或者由于某种未知原因,它使用的是 64 位版本的 Interop。

很奇怪,但现在正在运行。

I sorted this out.

I did a repair install of all my versions of Office, as i suspected it was a faulty Microsoft Interop DLL OR for some unknown reason, it was using a 64-bit version of the Interop.

Very weird, but its up an running now.

将军与妓 2024-12-03 19:35:57

VBA CreateObject() 调用用于实例化 COM 对象。有问题的 DLL 是否已正确注册以创建适当的注册表项?

The VBA CreateObject() call is used to instantiate COM objects. Has the DLL in question been properly registered to create the appropriate registry entries?

泪是无色的血 2024-12-03 19:35:57

64 位进程无法加载 32 位代码,反之亦然。您尝试过Excel x64吗?

64-bit processes cannot load 32-bit code and vica-versa. Have you tried Excel x64?

挥剑断情 2024-12-03 19:35:57

尝试比较您的计算机和正常运行的计算机之间的 PATH 环境变量。

这有点老式 - 但查找依赖 DLL 文件的搜索过程仍然使用 PATH 来查找文件。

如果 MyDLL 的依赖项之一位于计算机上的其他位置(不在同一目录或嵌套目录中),则缺少的 PATH 目录可能会导致加载程序失败。

Try comparing the PATH environment variable between your machine and one that works.

It's kind of old fashioned - but the search process for finding dependent DLL files still uses the PATH to find files.

If one of the dependencies of MyDLL is somewhere else on the machine (not in the same or a nested directory), a missing PATH directory could defeat the loader.

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