本文介绍了在C ++ / CLI项目中识别有问题的依赖项的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的应用程序编译正常,但我得到以下运行时错误:

  System.IO.FileNotFoundException未处理
HResult = -2147024770
消息=无法加载文件或程序集{Wrapper}或其一个依赖项。指定的模块无法找到。

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



这个项目用于在别人的系统上构建和运行,我看到它展示了几次。该人/计算机不再可用。一些依赖项的某些路径自上次成功构建和运行后已更改,我已修复与此相关的所有编译错误。



只是为了澄清我的项目结构:



 图形G 
{
App [label =My C#Application]
Wrapper [label =C ++ / CLI Wrapper ]
Lib [label =C ++ Library]
Dll [label =My helper C#DLL]
CDep [label =CM ++系列深层C ++依赖管理对于Lib,Wrapper的硬编码相对路径。]
App-> Wrapper-> Lib-> CDep;
App-> Dll-> Wrapper-> CDep;
}

Wrapper是C ++库的C ++ /当我们尝试在应用程序中加载一个包含Wrapper的using语句的类时,会触发错误。



Wrapper确实有很多依赖关系,但错误消息不指示哪个依赖性是有问题的。这是一个庞大,复杂的系统,其中大部分是由其他团队建造的。 C ++组件使用CMake获取所有依赖关系,但CMake本身不支持C#。



我试图使用fuslogvw查找绑定错误,但它显示了绝对直到我改变设置以包括所有绑定,然后它才显示成功绑定。



路径长,但不超过256个字符。 / p>

我在编译Dll时遇到了一个警告(参见上图):
警告1正在构建的项目的处理器体系结构不匹配MSIL 以及引用{cli_wrapper.dll},AMD64的处理器体系结构。这种不匹配可能导致运行时故障。请考虑通过配置管理器更改项目的目标处理器体系结构,以便在项目和引用之间调整处理器体系结构,或者依赖于具有与项目的目标处理器体系结构相匹配的处理器体系结构的引用。



在配置管理器中,Dll正在为平台任何CPU构建,并且Wrapper正在构建x64。我把dll改为x64。我仍然得到运行时错误。




执行一个干净,删除的构建目录内容。不用找了。
重新打开Visual Studio。不用找了。
尝试更改要匹配的程序集名称,默认名称空间和项目名称。无更改。




我相信我们必须编译64位。我们依赖于64位C ++库。




我是本地管理员。




尝试注册表设置,但它们似乎只是fuslogvw设置。



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

我发现了问题。有多个版本的库可用,我使用包含文件从一个版本和编译的库的其他。依赖Walker是找到哪个库有问题的关键,如果Aschratt发布了作为答案而不是一个评论,我会接受他的答案。


My application compiles fine, but I get the following runtime error:

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.

The reference to Wrapper in the calling Application looks correct. The Wrapper dll exists in the correct location.

This project used to build and run on someone else's system, I saw it demonstrated several times. That person/computer is no longer available. Some paths of some dependencies have changed since the last time it was successfully built and run, I have fixed all compile errors related to this.

Just to clarify my project structure:

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;
}

Wrapper is a C++/CLI wrapper around a C++ library. The error is triggered when we try to load a class in the Application that has a using statement for the Wrapper.

Wrapper does have a lot of dependencies, but the error message does not indicate which dependency is problematic. This is a large, complicated system, most of which is built by other teams. The C++ components use CMake to get all the dependencies correct, but CMake does not natively support C#.

I tried using fuslogvw to find the binding error, but it showed me absolutely nothing until I changed settings to include all binds, and then it only showed successful binds.http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.100).aspx

The paths are long, but not over 256 characters.

I had a warning in the compile for Dll (see graph above):Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "{cli_wrapper.dll}", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

In Configuration Manager, the Dll is building for Platform "Any CPU" and Wrapper is building for "x64". I changed the dll to x64. I still get the runtime error.

Could not load file or assembly or one of its dependenciesPerformed a clean, deleted build directory contents. No change.Re-opened Visual Studio. No change.Tried changing assembly name, default namespace, and project name to match. No change.

Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect formatI believe we have to compile for 64 bit. We are dependant on a 64 bit C++ library.

Could not load file or assembly ... The parameter is incorrectI am local administrator.

How to enable assembly bind failure logging (Fusion) in .NETTried the registry settings, but they appear to just be fuslogvw settings. No improvement in available log data.

Many other similar questions had ASP or service install specific answers.

解决方案

I found the problem. There was more than one version of the library available to me, and I was using the include files from one version and the compiled library of the other. Dependancy Walker was key to finding which library had the problem, and if Aschratt had posted that as an answer rather than as a comment I would have accepted his answer.

这篇关于在C ++ / CLI项目中识别有问题的依赖项的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-18 15:15