识别有问题的CLI项目依赖项中的C/C

Question

我的应用程序可以正常编译，但出现以下运行时错误：

System.IO.FileNotFoundException was unhandled
  HResult=-2147024770
  Message=Could not load file or assembly {Wrapper} or one of its dependencies. The specified module could not be found.

调用应用程序中对包装器的引用看起来是正确的。包装器dll存在于正确的位置。

这个项目曾经在别人的系统上构建和运行，我看了几次演示。那个人/电脑不再可用。自上次成功构建并运行以来，某些依赖项的某些路径已经更改，我已经修复了与此相关的所有编译错误。

为了澄清我的项目结构：

Digraph G
{
    App [ label = "My C# Application"]
    Wrapper [ label = "C++/CLI Wrapper"]
    Lib [ label = "C++ Library"]
    Dll [ label = "My helper C# DLL"]
    CDep [ label = "Series of deep C++ dependencies managed \n by CMake for Lib, hard coded relative paths for Wrapper."]
    App->Wrapper->Lib->CDep;
    App->Dll->Wrapper->CDep;
}

包装器是围绕C库的C /CLI包装器。当我们试图在应用程序中加载一个类时，会触发该错误，该类具有包装器的使用语句。

包装器确实有很多依赖项，但是错误消息并没有指出哪个依赖项有问题。这是一个庞大而复杂的系统，其中大部分是由其他团队构建的。C组件使用Cmake来获得所有正确的依赖关系，但是Cmake并不本机支持C#。

我尝试使用fuslogvw查找绑定错误，但在我更改设置以包含所有绑定之前，它完全没有显示任何内容，然后它只显示成功的绑定。http://msdn.microsoft.com/en-us/library/e74a18c4（v=vs.100）。aspx

路径很长，但不超过256个字符。

我在Dll的编译中有一个警告（见上图）：警告1正在构建的项目“MSIL”的处理器架构和参考“{cli_wrapper.dll}”、“AMD64”的处理器架构之间不匹配。这种不匹配可能导致运行时失败。请考虑通过配置管理器更改项目的目标处理器体系结构，以便在项目和引用之间对齐处理器体系结构，或者使用与项目的目标处理器体系结构相匹配的处理器体系结构来依赖引用。

在Configuration Manager中，Dll是为平台“任意CPU”构建的，包装器是为“x64”构建的。我将dll更改为x64。我仍然得到运行时错误。

无法加载文件或程序集或其某个依赖项执行了清理、删除的生成目录内容。没有变化。重新打开Visual Studio。没有变化。已尝试更改程序集名称、默认命名空间和项目名称以匹配。没有变化。

无法加载文件或程序集“xxx”或其依赖项之一。有人试图加载一个格式不正确的程序，我认为我们必须编译为64位。我们依赖于64位C库。

无法加载文件或程序集。。。参数不正确，我是本地管理员。

如何启用程序集绑定故障日志记录（融合）中。NET尝试了注册表设置，但它们似乎只是Fuslogvw设置。没有改进可用的日志数据。

许多其他类似的问题都有ASP或服务安装特定的答案。

Answer 1

我后来遇到的另一个根本原因是，我正在处理的应用程序使用模拟，而模拟用户没有访问GAC或某些DLL所在文件夹的权限。您需要授予该用户权限，或者更改进行模拟的方式，以便在模拟开始之前加载依赖项。

Answer 2

本周早些时候，我在一个类似的项目中也犯了同样的错误。首先，当使用C /CLI时，“任何CPU”不存在。我必须为x86构建两个来完成事情。

此外，虽然我的包装器的依赖关系得到了满足，但CLR捕获的是包装器的异常，因此它声明包装器缺少依赖关系。实际上，我缺少了包装器包装的C DLL的一个依赖项（在我的例子中，只是忘记了将SDL2.DLL和OpenAL32.DLL放在我新的“Release”配置输出文件夹中……我以前只使用调试配置，在那里我已经删除了那些DLL。

如果您确信已经解决了包装器的依赖项，我建议使用依赖项Walker检查本机DLL的依赖项。你可以使用汇编。GetReferencedAssembly与外部脚本/程序一起双重检查包装器（或ILSpy:http://ilspy.net/).

最后但同样重要的是，看看这个：http://www.codeproject.com/Articles/442784/Best-gotchas-of-Cplusplus-CLI.他详细介绍了我提出的前两个建议以及其他一些建议。

祝你好运

Answer 3

我发现了问题。我可以使用不止一个版本的库，我使用的是一个版本的include文件和另一个版本的编译库。依赖性沃克是找到哪个图书馆有问题的关键，如果阿斯克拉特把它作为一个答案而不是评论发表，我会接受他的答案。