28

I am building a dll, which references a second dll. I have added the second dll as a reference in the first dll's project by going to Properties > Common Properties > Framework and References > Add New Reference > Browse

I compiled the second dll from a third party's source code. Both projects are C++/CLI. Whenever my main application tries to call a function in the first dll which contains a call to the second dll, I get the following error:

An unhandled exception of type 'System.IO.FileNotFoundException' occurred in Unknown Module.

Additional information: Could not load file or assembly 'NBIS, Version=1.0.5156.29834, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

I have a copy of the second dll in the same directory as my main exe, and I've even tried keeping a copy next to the first dll as well, to no avail.

The second dll references several static libraries, but the only Assembly References it contains are

System

System.Data

System.Drawing

System.XML

All of which I have added as assembly references in the first dll.

What can I do to get my application to find and load the second dll?

Improve this question
8
  • 4
    "or one of its dependencies" Commented Feb 13, 2014 at 19:58
  • @HansPassant Since the only dynamic libraries referenced are the ones I've listed, wouldn't that suggest that it's not due to a dependency? Commented Feb 13, 2014 at 20:35
  • That assumes that you know what the dependencies are for nbis.dll. You don't know. The vendor or author knows. Commented Feb 13, 2014 at 21:01
  • @HansPassant I compiled nbis.dll from the author's source. The assemblies listed in the nbis project properties were: System, System.Data, System.Drawing, System.XML. All other dependencies were static libraries. Is there somewhere else dependencies might be hiding? Commented Feb 13, 2014 at 21:14
  • 4
    Use SysInternals' Process Monitor. You'll see your program searching for the DLL and not finding it. Commented Feb 13, 2014 at 21:15

6 Answers 6

Reset to default
37

As pointed out in the comments, SysInternals' Process Monitor is a valuable tool to diagnose DLL resolution problems. Tells you when a 3rd party DLL has a dependency you don't know about, also tells you when Windows is looking in the wrong corner of your hard drive for the file or finds the wrong one.

Loader snaps is the built-in diagnostic tool for Windows. But Process Monitor is far more convenient.

It does generate rather a lot of information, start from the bottom of the trace or enable tracing at just the right time. You often need to use its filtering tools to turn the firehose in a relevant trickle. Worth the hour of your time to figure it out, this tool belongs on any programmer's black belt.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

8

Right click on the project you created the dll and the new referencing project, then select properties. Under Application, check the target framework and verify that both have the same framework, some dll projects tend to select 'client profile' version of the framework by default, which tend to give the error you are having now..

Let me know if this is not the issue..

Improve this answer

2 Comments

Both projects target .NET v4.5 as you can see in these images: dll1 dll2
That worked for me, reference dll was .net framework and my project was .net 6.0. Thanks!
3

My PowerShell ISE wasn't running as an Administrator. This seemed to be the problem for me.

Improve this answer

Comments

0

Please Change your application pool setting.
Keep the steps:

  1. IIS manager open
  2. Click 'Application pools' (Application pools list)
  3. Select your application pool
  4. Right click your application pool and select 'Advanced settings '
  5. Change 'Enable 32-bit application' from false to true. (When you create application pool Enable 32-bit application default assign false)
Improve this answer

Comments

0

For the alert error ("The system cannot find the file specified.")

  1. Right click on [Solution Program name] then select Build Dependencies> & left click on Build Customizations... then true-checkbox {MASM} then click OK button.

  2. Right click on [Solution Program name] then left click on Properties, left click on "Linker" form "Linker" choose "Debugging" left click on "Debugging" from "Debugging" choose "Debugging Assembly" & convert the value of "Debugging Assembly" to "Yes (/ASSEMBLYDEBUG)", form "Linker" choose "System" left click on "System" from "System" choose "SubSystem" & convert the value of "SubSystem" to "Windows (/SUBSYSTEM:WINDOWS)",, left click on OK button.

  3. Right click on [Solution Program name] then Add> new item, "C++ File(.cpp)" change the name or rename "new item" to "Main.asm" then left click on Add button, Right click on [Main.asm] then left click on Properties select "General" from "General" choose "Item Type" and convert the value of "Item Type" to "Microsoft Macro Assembler" press left click on OK button, then then then Write your assembly code in "Main.asm" file then [[[Debug]]] it using 'step over === F10' from "Debug" tool-bar on top-screen program, all this about how to using assembly code in "Visual Studio 2017".

Improve this answer

Comments

0

after a significant amount of suffering I got here:

 <ItemGroup> <Reference Include="LIBNAME"> <HintPath>PATH_TO_LIB\bin\out\$(ContainerTaskFramework)\LIBNAME.dll</HintPath> </Reference> </ItemGroup>

here is a live example:

<ItemGroup> <Reference Include="atmocore"> <HintPath>..\..\..\atmocore\bin\out\$(ContainerTaskFramework)\atmocore.dll</HintPath> </Reference> </ItemGroup>
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.