.NET 4.6 Could not load file or assembly 'aaa' or one of its dependencies. The specified module could not be found RRS feed

  • Question

  • Hi,

    I have a C# Console application built in VS Professional 2017 (.NET Framework 4.6) with Target Platform set to x86.

    It is calling Unmanaged Dlls which are built with Platform “Active(Win32)”.

    Below is my C# code where I am getting the error:

    static void Main(string[] args)


                if( obj == null )
                    obj = MainFrame.GetMainFrameInstance(args);

                if (PriorProcess() != null)

                    if (obj.WindowState == FormWindowState.Minimized)
                        obj.WindowState = FormWindowState.Maximized;

                objEMRBrowserMutex = new Mutex( true, "Local\\EMRBrowserMutex" );

                if (objEMRBrowserMutex != null)

    From the Main function we are calling the below function and here we are getting the exception:

    System.IO.FileNotFoundException: 'Could not load file or assembly 'UIControl.dll' or one of its dependencies. The specified module could not be found.'

            public static MainFrame GetMainFrameInstance(string[] args)
                if (mainFrameObj == null)
                    lock (syncRoot)
                        mainFrameObj = new MainFrame(args);
                return mainFrameObj;

    Here, args showing {string[0]}


    Do I need to use try and catch for "Application.Run"

    like as shown below or is it not needed because anyway from the error we got to know that "Could not load 'UIControl.dll' ?

       catch(FileNotFoundException excep)
          MessageBox.Show("Missing file is : " + excep.FileName);


    I have added UIControl.dll from (Add -> Reference) as a reference to my C# project. But still i am getting the same error.
    I am beginner in C# programming. Please help me how to resolve the issue. And please provide your thoughts for marshaling and adding the references from C#.
    Tuesday, October 30, 2018 3:17 AM

All replies

  • First, I presume that UIControl.dll is a managed dll (otherwise you would not be able to add it as a reference).

    What you need to know is that adding a dll as a reference to a project only serves at compile time, so that the members in the dll can be resolved by the compiler. However, it is not enough to make the dll accessible at runtime. At runtime, the system follows a procedure known as fusion to try to locate the dll at various expected locations. The most obvious of these locations is the same folder that hosts the executable that calls the dll. By default, when you add a Reference in Visual Studio it enables a property that makes the dll be copied to the executable folder every time you compile. This is what lets the dll be loaded at runtime. So, first of all, check the properties of the Reference and verify that it is set to copy the dll.

    If this fails to work, it means that the DLL is not loaded normally from the executable, but rather it is called in some unusual way, maybe with one of the variants of loadassembly or indirectly from unmanaged code. You should try to locate where and how you are calling it from. If this proves to be too difficult, there is a tool calles FUSLOGVW ("fusion log viewer") that you can call from a Visual Studio command prompt. It can capture the fusion process and give you the details about what the program is trying to load and from where. Remember to run fuslogvw as Administrator, otherwise most of its options are grayed out and you can't capture anything.

    Tuesday, October 30, 2018 7:09 AM
  • Hi @Alberto,

    Thank you for the detailed information:

    For your information I am give some more details:

    1. My UIControl project has the below properties and it is the C++ wrapper to call the unmanaged code.

    Configuration type : Dynamic Library (.dll)
    Use of MFC: Use MFC in a Shared DLL
    Character Set : Use Unicode Character Set
    Common Language Runtime Support: Common Language Runtime Support (/clr)

    Linker -> Optimization

    References: Yes (/OPT:REF)
    Enable COMDAT Folding: Yes(/OPT:ICF)

    And I didn't give "Module Definition File" from Linker -> input. Because i don't have any functions to export.

    I think because of that reason it is not generating the UIControl.lib


    UIControl  project is there in different location and my C# project (EMRcs) is there in a different folder. I copied the UIControl.dll and UIControl.pdb to the EMRcs\bin\debug location. And added the dll reference. Is it the correct way to copy those files (.dll and .pdb) manually? Do we need to copy the complete project in to this folder? 


    As you said "when you add a Reference in Visual Studio it enables a property that makes the dll be copied to the executable folder every time you compile"  is it not required to copy the .dll and .pdb?


     And also as you said, How to check the properties of the Reference and verify that it is set to copy the dll?

    Tuesday, October 30, 2018 7:39 AM
  • To check the Reference, click on it in Solution Explorer and then examine the Properties window as shown in the following image:


    Don't worry about the .pdb files. They contain symbolic information for the debugger, which is not required for running the executable. You only need the DLL and any other files on which the DLL depends (such as other managed DLLs that it calls in turn).

    Copying the DLL (and its dependencies) should be enough, you don't need the complete project. But it is frequently useful to add the project to the same solution, since you will be able to easily modify and debug both projects simultaneously. In this case, add a Project Reference (not a Reference to the DLL), so that Visual Studio knows to update it when you make changes to its source code.

    I am still not clear about the type of project that you are writing with C++ (I normally work with C#, not C++). Is it a Managed DLL? Or are you creating a COM object and referencing it through COM/Interop? All the previous discussion refers to a Managed DLL; if you are doing COM, things are different: it would need to be registered in the Windows Registry, and then you would need to copy the Interop DLL to the client application.

    Another couple of things: Be careful with the .Net version of the caller and the callee (modern .net consumer can call older .net dll, but not the other way round). Also, if the executable runs in 32 bits it cannot call a dll that is 64-bit only and viceversa.

    Tuesday, October 30, 2018 1:58 PM