FileNotFoundException when calling C# dll from C++/CLI

Question

I have a C# dll, with some methods, which I am trying to access in my native project with /CLR support.

I reference this DLL using a #using directive, and the DLL is recognized and the project compiles.

However, during runtime, I get a FileNotFoundException, which is pretty weird since the DLL is present in the source directory of the project.

TheDLL is compiled inVS 2015 with .NET Version 4.5.2. Since I have CLR support on my C++ mixed, I have edited the project file to make TargetFrameworkVersion as 4.5.2, but still the runtime does not work.

Kindly advise on what could be the issue?

EIDT - ADDED SOME CODE

C#

namespace TestManagedLibrary
{
    public class Class1
    {
        public int i;
        public Class1()
        {
            i = 5;
        }

        public int returnValue()
        {
            return i;
        }
    }
}

C++/CLI

#using <TestManagedLibrary.dll>


using namespace System;
using namespace System::Runtime::InteropServices; // Marshal
using namespace TestManagedLibrary;


ref class ManagedFoo
{
public:
    ManagedFoo()
    {
        Console::WriteLine(_T("Constructing ManagedFoo"));
        Class1 ^testObject = gcnew Class1();
        int a = testObject->returnValue();
    }
};

Could be that the DLL references another DLL & it is that which cannot be found or you have a 32/64bit mismatch : http://stackoverflow.com/questions/8224134/filenotfoundexception-dll-not-found — PaulF, Aug 30 '16 at 14:35
@PaulF No, the C# DLL does not refer to any other library. It is just a very simply library that returns the value of an integer to the calling function. Both calling and called are in x64, and would I not get a BadImageFormat exception if this were the case? — user1173240, Aug 30 '16 at 14:36
@MethodMan I have added some code. I am not able to use the debugger to step into the `C#` code, the moment that I try and initialize the `C++/CLI` class object that refers the C# class, I get a `FileNotFoundException'. Both have the same Target Framework. I am able, of course, to see the definition of the` C# `class and its member functions. — user1173240, Aug 30 '16 at 14:43
by default without declaring the scope of the variable `i` it's private if I am not mistaken. what if you declare it as `public int i` — MethodMan, Aug 30 '16 at 14:43
@MethodMan Wouldn't that cause a problem when I actually try and refer the function? In my case I am not able to step into the constructor at all. By the way, I tried it, but it did not work, still file not found. — user1173240, Aug 30 '16 at 14:48
"the DLL is present in the source directory of the project". Well, bad place, the CLR is never going to look for it there. It belongs in the same directory as the EXE. If necessary use a post-build event to xcopy the file there. — Hans Passant, Aug 30 '16 at 15:04
@MethodMan Scope of the `i` variable has nothing to do with the problem. First the `i` is not accessed from anywhere besides the class it is defined in and thus it should be private. Second it is generally a bad habit to make public fields. — Zverev Evgeniy, Aug 30 '16 at 15:21
@HansPassant OK, turns out you are correct. It should have been in the same location as the EXE. Putting it there, worked immediately, Thanks a lot. If you write it out as a solution, I shall accept it. — user1173240, Aug 30 '16 at 16:19

score 3 · Accepted Answer · edited May 23 '17 at 11:51

First of all you need to ensure that the TestManagedLibrary.dll file is located in a place where Fusion could find it. Your first try should be the location of the executable you are running.

One way to handle this is via the reference properties. If the reference to your TestManagedLibrary.dll is set with the copy local flag than during the build the referenced library is going to be copied from the referenced location to the output directory.

You can enable the internal fusion logging to find out the details:

Run Developer Command Prompt with administrative privileges.
Run fuslogvw
In the Assembly Binding Log Viewer hit settings and set either Log bind failures to disk or Log all binds to disk.
Start your service
Hit Refresh in the Assembly Binding Log Viewer, pick your executable and hit View Log

score 0 · Answer 2 · answered Aug 31 '16 at 07:46

0

The compiled DLL should have been in the same location as the executable for the CLR to search for it. In my case, the .NET compiled DLL was in the solution folder and not searchable.

answered Aug 31 '16 at 07:46

user1173240

1,455
2
23
50

So it is. Thank you. – user1173240 Aug 31 '16 at 16:02

FileNotFoundException when calling C# dll from C++/CLI

2 Answers2