为什么SAP Hana DB ADO.NET DLL加载可能失败？

对于使用

SAP.DATA.HANA.v4.5

v2.3.119的.Net C#应用程序，安装在运行时计算机上的

libadonetHDB.dll

v2.3.119，环境变量

HDBADONET

指向存在

libadonetHDB.dll

的应用程序文件夹。到目前为止，该应用程序在多个安装上都能按预期工作，但是我发现有一个新安装失败，产生了无法找到指定模块错误以下连接异常：

The type initializer for 'Sap.Data.Hana.HanaConnection' threw an exception.
System.Exception: The specified module could not be found
   at Sap.Data.Hana.HanaUnmanagedDll.LoadDll(String dllPath)
   at Sap.Data.Hana.HanaUnmanagedDll..ctor()
   at Sap.Data.Hana.HanaUnmanagedDll.get_Instance()
   at Sap.Data.Hana.HanaConnection..cctor()

还尝试将dll移动到安装应用程序的同一文件夹中，并生成相同的结果

根据，dll与应用程序位于同一文件夹中，或者通过

HDBADONET

环境变量路径位置，应该可以工作（并且在其他几个安装中也有使用过）。这是为非本机.NET应用程序开发和使用ADO.NET库的一般工作流的一部分

我作为“管理员”用户一直在尝试此操作，这是一个全新创建的虚拟机（尝试了新的Windows10 x64虚拟机和新的Windows Server 2016 x64虚拟机）。还确认安装了.NET v4.5+

计算机是否可能具有影响DLL加载的权限或其他策略

关于为什么SAP Hana ADO.NET DB连接DLL加载会失败（但并非所有情况下都会失败）的任何线索

由于某种原因，

libadonetHDB.dll

是否仍在尝试查找和加载

libSQLDBCHDB.dll

或计算机上的其他dll？据我所知，使用ADO.NET DLL允许机器不需要安装其他客户端和DLL

哪个

模块

无法找到？有没有办法让Hana连接DLL加载在失败时生成更详细的输出

更新

为了确认使用

HDBADONET

环境变量定义确实找到了

libadonetHDB.dll

，我删除了该文件并重新测试，得到了一条不同的消息：

The type initializer for 'Sap.Data.Hana.HanaConnection' threw an exception.
System.IO.FileNotFoundException: Cannot find a matching libadonetHDB.dll 
with version 2.3.119 - check the location in the HDBADONET or PATH 
environment variables
   at Sap.Data.Hana.HanaUnmanagedDll.SearchNativeDlls()
   at Sap.Data.Hana.HanaUnmanagedDll..ctor()
   at Sap.Data.Hana.HanaUnmanagedDll.get_Instance()
   at Sap.Data.Hana.HanaConnection..cctor()

因此，原始帖子中发布的消息是在成功找到

libadonetHDB.dll

之后出现的。因此，异常消息中关于无法找到或加载模块的抱怨似乎是指它正在查找的其他资源或dll，但该消息不够详细，无法知道这是什么。有什么想法吗

更新（解决方案）

简单的回答是：

通过检查

libadonetHDB.dll

，发现运行时计算机上由于某种原因缺少

msvcr100.dll

和

msvcp100.dll

。将这些丢失的DLL添加到应用程序的安装包中解决了该问题

较长的答案是：

感谢您建议查询DLL以查看其依赖项。我在出现故障的机器上使用的工具是（它需要安装vc++可再发行x64，如自述文件中所述，以使其正常工作），它显示

msvcr100.dll

和

msvcp100.dll

在检查

libadonetHDB.dll

时都作为依赖项丢失。请注意，它们只在这台新创建的虚拟机上丢失，因此检查和测试用例必须在这台机器上进行

安装时包含缺失dll的解决方案可以是将

msvcr100.dll

和

msvcp100.dll

添加到以下任一位置：

• C:\Windows\System32

  （如果希望应用程序避免将内容安装到主系统文件夹中，可能不是首选解决方案）
• 应用程序的exe所在的文件夹也存在
• 只要将应用程序的lib子文件夹的路径添加到

  path

  环境变量定义中（即

  set path=%path%；fullpath\to\app\lib

  ）

---

这两个DLL已经出现在我们的开发机器上，并且可能已经是许多运行时/客户端机器的一部分，这些机器已经存在了一段时间，并且有其他需要它们的软件。如果您甚至在开发过程中也没有这些软件，那么可以从Microsoft的官方软件包中下载它们（如果您希望确保它们不是隐藏在dll中的恶意软件，请避免从第三方dll网站获取它们）。理想情况下，SAP HanaDB ADO.NET库的文档应提及运行时计算机的要求或.NET开发人员需要提供这些依赖DLL的要求。

我的建议是使用Dependency Walker（或其他类似的util）确定找到的DLL要查找的DLL。看起来找到了一个，但在这种情况下并不是所有的符号依赖都得到了满足

---

Streamline提出了一个很好的观点：所看到的故障是运行时故障，而不是构建时故障。运行时环境各不相同，因此为满足所需符号而选择的DLL可能不同。必须在遇到异常的特定系统上进行故障排除。

您是否尝试Dependency Walker查看您的DLL可能要加载的其他DLL？我没有。我假设它会安装在运行时机器上，并监控应用程序的运行时执行情况？这是我对它的理解（对我来说是新的）。在Linux中，我可以使用strace或ktrace查看大量（嘈杂的）“引擎盖下”的信息，了解正在发生的事情，并且它经常会显示我无法以其他方式获得的信息。这看起来同样有用，但重点放在了DLL上。另外，FWIW，Dependency Walker是免费的。我尝试了Dependency Walker，但它给出了一系列错误的负面反馈，并且我尝试了另一个名为的工具（首先需要安装vc++可再发行x64）如果我解释正确，它似乎表明

MSVCR100.dll

丢失。当我们的.NET应用程序在VisualStudio中构建时，为什么不包括这些内容？搜索