Develop Reference

File not found exception for DDL file during runtime

So I have a solution with 3 projects. One of the projects is built as a class library and is referencing a third party DLL. When I am building the solution everything is just fine. However, when I run the program and call a method inside my class library I get a "File not found" exception for the referenced third party DLL.
When I look in the output folder I can see the DLL.
I also tried to load it using:
Assembly.LoadFile("absolutePathToFileInOutputFolder")
Still getting the same exception. But if I use the path to another copy of the DLL it works.
So what could be the reason for this behaviour? Can it be that one of my projects are locking the DLL for the other projects?

This is a recurrent issue once in a while in Visual Studio. Usually it corrects itself setting the reference to said DLL on the Properties Window with CopyToLocal = True.

Registering a COM object created with VS C# 2010

I created a COM object with C# yesterday which resulted in three files in the bin/release directory of my VS 2010 project (comclass.dll, comclass.pdb and comclass.tlb). Now, when I build the solution in the project, VS registers the class for me automatically on the development PC and I have no problem accessing the COM object and its methods from, let's say, Powershell. However, when I copy the three files onto a different machine and try to register the dll with regsvr32, it tells me that
the module "comclass.dll" was loaded but the entry-point DllRegisterServer was not found.
Make sure that "comclass.dll" is a valid DLL or OCX file and then try again.
Using regasm with the /tlb parameter on the .tlb file gives me a similar message. So I am a little bit stumped. Anyone knows how I should proceed from here?

Just copy the dll (and optionally the pdb if you want file paths and line numbers in your stack traces). This is how you register it, and the tlb is created:
"%WINDIR%\Microsoft.NET\Framework\v2.0.50727\regasm.exe" comclass.dll /tlb /nologo /codebase
Since Visual Studio successfully registers it, that might just work. If not, you could also open the Output panel while doing a Rebuild and see how Visual Studio calls regasm.

How do I add a reference to an unmanaged C++ project called by a C# project?

One solution (the.sln)
One C++ project (mycppproject.vcxproj in 2010or mycppproject.vcproj in 2008) which compiles a native DLL exporting some function(s). In debug this builds c:\output\Debug\mycppproject_d.dll and in release this builds c:\output\Release\mycppproject.dll.
One C# console application (mycsharpconsole.csproj) containing PInvoke calls into the DLL.
All compiles fine.
When I build, I would like to be able to add a reference from the csharp project to the cpp DLL project so that it can copy the appropriate file from the appropriate directory into the \bin\Debug directory the csharp project is built into.
This should be possible, since the IDE knows everything there is to know about where the DLL gets built, and where the C# application gets built.
In Visual Studio 2010:
I've tried "Dependencies..." on the csharp project and adding a dependency on mycppproject, but that has no effect.
I've tried "Add Reference..." on the csharp project and adding a reference to the cpp project, but I get a warning message 'The Target Framework version for the project "mycppproject" is higher than the current project Target Framework version. Would you like to add this reference to your project anyway?' (Yes/No/Cancel).
Clicking "Yes" produces the error message "A reference to mycppproject" could not be added."

You cannot add a reference to an unmanaged DLL.
Instead, you should make a post-build task to copy the file.
Alternatively, you can add a link to the unmanaged DLL as a file in the C# project, and set Build Action to None and Copy to Output Directory to Copy If Newer.

Visual Studio doesn't support referencing an unmanaged C++ project from a managed C# one, but MSBuild supports referencing any project from any other project.
You can manually add a reference to your project by editing the .csproj file by hand. In the file, find your existing set of ProjectReference elements (or add a new ItemGroup if you don't have one) and add the following reference:
<ProjectReference Include="..\mycpproject.csproj">
<Project>{b402782f-de0a-41fa-b364-60612a786fb2}</Project>
<Name>mycppproject</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Content</OutputItemType>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</ProjectReference>
When you perform the build, the reference will cause MSBuild to build the referenced project first. The ReferenceOutputAssembly value tells MSBuild not to copy the output assembly of the build (since the C++ project does not produce one), but the OutputItemType and CopyToOutputDirectory values instruct it to copy the output content to the referencing project's output folder.
You will be able to see the reference in Visual Studio, but you can't do much with it there.
This answer is based on a similar problem solved by Kirill Osenkov on his MSDN blog: https://blogs.msdn.microsoft.com/kirillosenkov/2015/04/04/how-to-have-a-project-reference-without-referencing-the-actual-binary/

I would follow Slaks' second answer...
[...] you can add a link to the unmanaged DLL as a file in the C# project, and set Build Action to None and Copy to Output Directory to Copy If Newer.
... followed by my comment, to differentiate between Debug and Release builds (even if is a little bit "hackish", since it requires you to manually edit the C# project file)
open your C# project's csproj file with a text editor and search for all "YourNativeCppProject.dll" occurrences (without the ".dll" subfix, so if you added pdb files as a link too, you'll find more than one occurrence), and change the Include path using macros, for example: Include="$(SolutionDir)$(ConfigurationName)\YourNativeCppProject.dll
PS: if you look at the properties (F4), VS shows you the Debug's path even if you switch to the Release configuration, but if you compile, you'll see that the dll copied to output is the release version*

Add Rederences only works for .NET assemblies, .net projects in the same solution or for COM components ( for which a manager wrapper will be created anyway... ).
the fact that in your C# code you access the C++ dll with DLLImport does not mean that Visual Studio will know from where to where the external dll should be copied.
Imagine that DLLImport is a runtime option, the path you puth in there is used at runtime to look for the dll, so you have to deploy the c++ dll yourself and make it available for the .net application, usually in the same bin folder.

Where to place an unmanaged DLL for use importing into a C# program?

This must be a really stupid question, but I'm still very green when it comes to C#.
Anyway, I've got a DLL and I'm importing it with a line like this:
[DllImport(#"MyCoolDll")]
I've lifted this straight from the demo app provided by the vendor, but it keep complaining that it can't find the DLL. The actual error (from Visual Studio 2010) is like this:
Unable to load DLL 'MyCoolDll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I've tried placing the compiled DLL in the bin/debug and bin/release folders. I've even tried copying it to system32, but nothing seems to work.
Any ideas?

Your DLL may have dependencies that also need to be loaded. Did you check for that?

I know you have to give the full file name. So
[DllImport(#"MyCoolDll.dll")]
It should work from the bin\debug or bin\release folders.
Update
This is where I learned how to import unmanaged dlls. If it was a test app that is working correctly, check it's bin\debug folder to see what is different from yours. Possibly an extra dll being referenced? Also check all the references within the sample app to make sure you are not missing any.

As far as I know you have to provide extension:
[DllImport(#"MyCoolDll.dll")]
I usually keep these dlls locally with the program binaries (so in bin\Debug for development)

The key for me was to look at the paths listed in the Visual Studio Build console output, to see where the binaries were being placed. Once I found that, I knew where to copy the unmanaged dll and it fixed the "Unable to load DLL" error.

Problems adding a UserControl referencing a C++/CLI wrapper to a unmanaged dll to a form

My UserControl references a C++/CLI wrapper to an unmanaged C++ dll. When I try to add the UserControl to a form, I get a Visual Studio error, which says "Failed to create component 'userControl'", giving a System.IO.FileNotFoundException as the cause.
From what I've been able to determine, the problem stems from visual studio not copying the C++/CLI wrapper assembly's unmanaged dependencies. If I put the unmanaged dependencies on the system PATH, everything works fine.
Is there a better way of doing this?

The easiest thing to do would be to include the actual .dll in your project, mark its build action as "Content", then set the Copy to Output Directory to "Always". This should get the .dll into your output directory so that your application can run, and just including the file in the project should put it in the project directory so that the designer can find it.
Be sure that your setup project includes a project output for the Content files from that project as well.
Edit
If those don't work, you can also edit the reference paths of the project itself (in the project properties), though I am not certain that this will affect the designer. If that doesn't then your only real option is to have the .dll in one of the system path directories.

Old thread, but submitting my solution since I just encountered the issue and found this question during the process.
Basically I just made the native DLLs to be delay loaded in my wrapper C++/CLI library. Since the C++/CLI part of the wrapper contains the interface specs used by Visual Studio and the framework, the native DLL is never needed or loaded. I answered it with a little more details in this question too:
https://stackoverflow.com/a/15481687/34440