Dllimport 无法导入旧的 Borland dll

Question

我有很多遗留代码，目前使用 Borland C++ 3.0 的过时安装进行编译。

我想在这段代码中提取一个规则引擎并在 C# .NET 应用程序中使用。

问题是，如果我将规则引擎提取到它自己的 DLL 中，我希望能够从我没有时间移植的现有遗留代码和 C# .NET 应用程序中调用此 DLL。

如果我使用旧的 Borland 编译器构建 DLL，我无法弄清楚如何从 C# .Net 项目引用它。 DllImport 失败并出现 BadImageFormatException。谷歌搜索此异常表明大多数人在编译 64 位功能的程序并向其中加载 32 位程序时都会遇到此问题。问题是，我相当确定我正在生成 16 位 DLL，并且似乎没有解决方法。

我可以下载较新的 Borland 5 编译器，它有 32 位编译器和链接器，但我仍然遇到同样的问题，所以也许我也有问题。

这是我的 C# 调用代码

[DllImport( "C:\\NSDB\\BorlandDLL\\BorlandDLL.dll", ExactSpelling = false, CallingConvention = CallingConvention.Cdecl )]
static extern int Version();

public frmHelpAbout()
{
    InitializeComponent();

    lblIssueVersion.Text =  + Version();
}

这是我的 DLL 代码

int Version()
{
    return 93;
}

我的编译器标志和链接器标志都是完全猜测 - 我希望这是我的主要问题

我注意到我的 DLL 代码没有用 __stdcall、extern "C" 或任何。我似乎无法找到 Borland C++ 3.0 可以理解的正确符号集来强制执行我需要的调用约定。

因此，问题是：

1) DllImport 是否能够使用 Borland C++ 3.0 生成的代码 1b) 如果没有，我是否能够将代码移植到 Borland C+ 5.5.1 编译器上，并让 DllImport 来使用它？

2）我能扭转这个问题吗？如果我将 DLL 代码移植到 .NET 中，我是否能够让旧的 Borland 代码来调用它？

3) 你们是否有任何其他创新的解决方案可以让我简单地从这个旧的 Borland 项目中提取我需要的代码？

Answer 1

据我所知，DllImport 仅适用于与 .Net 应用程序字大小相同的非托管 dll。例如，64 位 .Net 应用程序中的 DllImport 仅适用于 64 位 dll，32 位 .Net 应用程序只能加载 32 位 dll，等等。我也不认为可以让 DllImport 加载16 位动态链接库。

我想到了一些可能的解决方案：

1. Steve 提到使用 COM。如果您想将 .Net 应用程序保持为 64 位，您可以使用 COM 来使事情像这样工作：将 C 代码重新编译为 32 位 dll，使用 .Net 为该 dll 编写 32 位 COM 包装器，然后让您的 64 位 .Net 应用程序调用 32 位 COM 服务器，该服务器又会调用您的 32 位 dll。 MSDN 提供了一些有关与非托管代码互操作的信息。

2. 编译 32 位的 dll 和 .Net 应用程序。 DllImport 应该能够加载 dll。 （您可能需要将 C 代码包装在 extern "C" 中，并在 dll 上运行 TDUMP 或 DUMPBIN 实用程序来检查名称修改）。

3. 如果您拥有所有 C 源代码，您是否可以忘记 Borland 编译器并使用 Visual Studio 的 C++ 编译器构建代码？

Answer 2

.net 将调用 COM 并且可以非常愉快地调用 COM（对于适当的 COM 调整的 happy 值），因此如果旧的本机代码提供了合适的 COM 接口，您可以尝试直接使用它（但这需要使用32 位版本）。

如果您不需要所有内容都在一个进程中，另一种方法是将代码构建为 C++/CLI 程序集和 Borland DLL（如果您有 .c 文件，则您将需要 .cpp 文件，这些文件只是 .net 项目中的 #include .c 文件）。

Answer 3

如果您同时使用 32 位 .NET 和 32 位 C-DLL，则应该不会有问题。我几乎 100% 确定您无法轻松地从 32 位应用程序调用 16 位代码（尽管我认为我已经看到了这样做的解决方案 - 这里我想到了“thunking”这个词？）。

如果 .NET 和 DLL 都是 32 位，那么您应该可以接受上面所做的操作，但我记得 Borland DLL 存在一些问题，这使得它们与其他“普通”C-DLL 不兼容。

我认为 Steve Gilham 关于 COM 的答案可以忽略，因为在您的情况下 COM 既不是必要的，也不是一个好的选择。