10

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:

Graph

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 dependencies Performed 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 format I 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 incorrect I am local administrator.

How to enable assembly bind failure logging (Fusion) in .NET Tried 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.

Community
  • 1
  • 1
Denise Skidmore
  • 2,286
  • 22
  • 51
  • 3
    +1. Bump. Anyone that even hints at a suggestion of "What have you tried?" should be beaten with an iron pipe. I'm not a CLI/.NET guy so I have no answer for this, but I sincerely hope you find one. You deserve it, if for nothing else than the presentation of this question, which is *remarkable*. – WhozCraig Apr 29 '14 at 19:37
  • Thanks. Usually when I build one of these I end up answering my own question before I post, but not this time. – Denise Skidmore Apr 29 '14 at 19:57
  • Additional info: The Wrapper uses a prebuild event to call the build of one of it's dependencies, but most of the dependencies are pre-built 64 bit static libraries. – Denise Skidmore Apr 29 '14 at 20:30
  • If I could list all the dependencies, how would I verify they are all compiled for 64 bit? Just because I fetched them from the 64 bit release folder doesn't mean they are correct. – Denise Skidmore Apr 29 '14 at 21:03
  • Since this looks like a JIT problem, I tried compiling with ngen, I apparently need to find the 64bit ngen to do that. – Denise Skidmore Apr 29 '14 at 21:30
  • No luck with ngen. Compiled with no helpful errors. Still can't run the application. Debugger hangs in same spot with same error. – Denise Skidmore Apr 29 '14 at 21:55
  • 1
    Good question! First of all, if your unmanaged libraries are build for x64 environments, then all your managed components need to be build for x64, instead of AnyCPU. However, you would experience `BadImageException`s if there was a cpu architecture missmatch. My question is: When exactly does the runtime error occur? The first time your application calls into the wrapper? Or sooner/later? Also you could try loading your wrapper library into [Dependency Walker](http://www.dependencywalker.com/). It already helped me out alot! – Carsten Apr 30 '14 at 08:29
  • I just got a good lead. Someone on another team just sent the system architect an angry note wanting to know who compiled library x for Windows. System architect decided to blame me so I found out about it. Library x is several levels down in my dependency tree, and I do see the build warnings the angry engineer is discussing. – Denise Skidmore Apr 30 '14 at 14:00
  • Dependency Walker was a very good tip. Perhaps my error is not the same as the other guy's problem after all. Dependancy walker has problems opening these files:API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL API-MS-WIN-CORE-WINRT-L1-1-0.DLL API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL DCOMP.DLL IESHIMS.DLL – Denise Skidmore Apr 30 '14 at 14:08
  • ... but Wrapper didn't show up at all in the tree. When I load Wrapper in Dependency Walker I see I'm missing a locally installed driver I totally forgot I would need. – Denise Skidmore Apr 30 '14 at 14:11
  • @Aschratt If you post Dependency Walker as a solution I'll accept it. I have a different problem now, but I've gotten past the original question. "A procedure imported by {Wrapper} could not be loaded." – Denise Skidmore Apr 30 '14 at 14:48
  • http://stackoverflow.com/questions/17023419/win-7-64-bit-dll-problems indicates that at least one of my missing dlls is not an actual problem. – Denise Skidmore Apr 30 '14 at 15:53
  • sfc /scannow did not find any integrity violations – Denise Skidmore Apr 30 '14 at 16:00
  • Somehow in my debugging I buried the exception. See http://stackoverflow.com/questions/4129925/form-load-event-not-firing-form-showing for debugging – Denise Skidmore May 02 '14 at 20:22
  • @DeniseSkidmore: Your first link seems to fit your problem. You can look up "Programs and Features" to find out which vc redist packages are missing on your development machine. However it looks like VC2013 or VC2012. You should be able to download and install them to fix your problem. You can download them [here](http://www.microsoft.com/en-us/download/details.aspx?id=40784). – Carsten May 05 '14 at 07:47
  • Important note. When you turn on fusion logging, it is going to considerably slow down visual studio. Disable it after you have diagnosed your problem. – Denise Skidmore Mar 02 '15 at 14:53
  • I also have this problem. I figured out that I need to add the directory of those native C++ dlls to the PATH. You can find more here http://blogs.msdn.com/b/jorman/archive/2007/08/31/loading-c-assemblies-in-asp-net.aspx – Bargitta May 06 '15 at 09:26

3 Answers3

6

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.

Denise Skidmore
  • 2,286
  • 22
  • 51
3

I had the same error with a similar project earlier this week. First, when using C++/CLI, "Any CPU" doesn't exist. I had to build both for x86 to get through things.

Also, though my wrapper's dependencies were satisfied, it's the wrapper's exception that is caught by the CLR so it claims that the wrapper is missing a dependency. I was actually missing a dependency for the C++ DLL my wrapper wrapped (in my case, it was just a matter of forgetting to drop SDL2.dll and OpenAL32.dll in my new "Release" configuration output folder... I'd previously only worked with the Debug configuration where I'd already dropped those DLLs.

If you're positive you've got your wrapper's dependencies worked out, I'd recommend using Dependency Walker to check out the native DLL's dependencies. You could use Assembly.GetReferencedAssemblies with an outside script/program to double-check your wrapper as well (or ILSpy: http://ilspy.net/).

Last but not least, take a look at this: http://www.codeproject.com/Articles/442784/Best-gotchas-of-Cplusplus-CLI. He details the first two recommendations I made as well as some others.

Good luck!

sraboy
  • 903
  • 2
  • 13
  • 26
0

One alternate root cause I've been running into quite a bit later, is that the application I'm working on uses impersonation, and the impersonated user does not have permissions to the GAC or to the folder that some dlls are in. You need to either give that user permissions, or change the way you do impersonation to load the dependencies before impersonation starts.

Denise Skidmore
  • 2,286
  • 22
  • 51