How to Use a Third-Party Dll File in Visual Studio C++

How do I use a third-party DLL file in Visual Studio C++?

As everyone else says, LoadLibrary is the hard way to do it, and is hardly ever necessary.

The DLL should have come with a .lib file for linking, and one or more header files to #include into your sources. The header files will define the classes and function prototypes that you can use from the DLL. You will need this even if you use LoadLibrary.

To link with the library, you might have to add the .lib file to the project configuration under Linker/Input/Additional Dependencies.

Third party dll added in visual studio: are you missing a using directive or an assembly reference

Open your project in visual studio then go to solution explorer window. There you will see a section as references, right click on references, select add reference option from the menu. A window will appear, at bottom there's an option to browse, now locate the Tester.dll, build the application. Your code should now compile successfully.

Note: Class which you are trying to access from Tester.dll should be marked with public access modifier.

Visual Studio - Referencing third party DLL

I would typically put a Library folder in my application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into your source control.
Now, anyone that pulls your source will have the required dll.

C++ Linking 3rd party dll in diffrent directory

First we should distinguish two scenarios:

1) Load-Time Dynamic Linking - when you link your code against a stub library to resolve the references to the functions of the DLL at link time and then the system tries to load the DLL when the program starts (and terminates the program if the DLL is not found) and you have basically no control of that. Judging from what you have said you are using this option.

2) Run-Time Dynamic Linking - when you load the DLL yourself by LoadLibrary/LoadLibraryEx and resolve the needed symbols at runtime. Here you have much greater control of what is going on (among other thins you have the ability to specify what and from where to load). Maybe it makes sense to switch to this mechanism if you need a custom layout?

So what needs to happen for both scenarios to work:

1) The system basically searches for the DLL you are trying to load and any DLLs it may depend on in a set of predefined search paths. So, as mentioned by m.s. you can append the path that contains your DLL to PATH variable and then the system will be able to find it. But that is only one of the places system looks for the DLL in. Here is a full description. In short the most important places in order of search are:

The directory from which the application loaded.
The system directory.
The Windows directory.
The current directory.
The directories that are listed in the PATH environment variable.

So this explains why adding to PATH works and is also considered a normal approach, since tweaking with the current directory (which you can do) can do bad stuff.

2) In this scenario you are on your own. LoadLibraryEx gives the ability to alter your search path, by using SetDefaultDllDirectories or LOAD_WITH_ALTERED_SEARCH_PATH to load the DLL and any dependencies.

Cannot access third-party DLL from my.exe

Dynamic-Link Library Search Order only works for native code. You are using a managed assembly, here is how lookup works for .NET: How the Runtime Locates Assemblies