I'm on Windows 10, Visual Studio 2017, x64 build . . .
I have a DLL that I'm using in an exe project. We'll call it, myLibrary.dll. It comes with a .lib companion file as well. The myLibrary.dll has some other DLL dependencies that it is using. We'll call that one theDependency.dll.
I've linked the companion myLibrary.lib file in my project through Linker --> General --> Additional Library Dependencies properties. Added myLibrary.lib to the Additional Dependencies.
When I build my project, I use post build event to copy the myLibrary.dll to the Release/Debug directory of my project.
This works fine.
My issue is when I try to use myLibrary.dll in a different exe project. I get an error that it cannot find the theDependency.dll. I've used all the same property setup as the first exe project. As a test, I moved the build directory of the first exe project to another location (on the same computer) and I get the same error. "Cannot find theDependency.dll"
How is myLibrary.dll targeting it's dependencies? Not sure why the 2nd project gets this error? Also, not sure why moving the files gets this error?
Any ideas? Thanks.
Adding the path of the dll to the PATH environment variable worked for me.
I have downloaded the Autodesk fbx sdk and trying to build a simple console app. I have added additional directories in Linker / General / Additional Library Directories like follows:
see the screenshot of the directory below. There are several libs that (I suppose) I should add in dependencies, and there's also the .dll file. It's release folder (debug is another available), for x86 architecture and for VS2017 which I am using.
Also, I have add dependencies like below and have included the standard include folder as specified in the Autodesk manual
The project builds fine but shows the following when run:
Cannot run code because libfbxsdk.dll could not be found...
But it is in the folder as you can see in the pic. Could you pls help?
The linker settings have nothing to do with finding DLL files at run-time. If you want this SDK to be available to all programs - which without reason to do otherwise would be my recommendation - hit the start button and search for "environment", choosing "Edit environment variables for your account". Edit the value of the PATH environment variable (adding it if necessary) to include the directories where the DLLs are located.
If you only want it to be available to this particualr program (and you don't have any other custom DLLs that need to be found) you could also change the startup directory in the project properties to the directory where the DLL files can be found (the startup directory is one of the locations in the system search path).
I have two C++ solutions in Visual Studio.
My 1st solution is used to generate a lib file. The Project Settings are C/C++ -> General -> Debug Information Format = "C7 Compatible (/Z7)". Everything builds correctly and is debuggable from my 1st solution (I have a second project with a main which allows for testing).
For my second solution in project properties C/C++ -> General I list the Additional Include Directories. I specify the additional library directories for the linker. And I specify the lib file in Additional Dependencies. My solution builds and runs correctly. However, when trying to step through code in the debugger from solution 1 some cpp files are automatically found. However, other files will show the "Find Source" dialog box. Is there a way to get VS to automatically find all source files from the lib generated by project 1?
I have only had a problem with this when the code is in a dll and their companion pdb files are not in the same folder. This typically happens when you copy the dlls at runtime but do not copy the pdbs.
I have a project that relies on some other projects on my solution. For example assume that my main project is m and it produce m.exe
This project depends on some other projects say a.dll, b.dll,c.dll.
My problem is:
when I build m.exe, a.dll,b.dll and c.dll are created and the output is placed in some directory on my pc, but these dlls are not copied to output directory of m.exe and hence when I want to debug m.exe, they are not found.
If I copied them to output directory (debug directory) the application runs, but I am not able to debug into a.dll,b.dll and c.dll.
How can setup my MSVC so I can compile and debug into these dlls?
I am using Visual studio 2012.
In your project settings (Configuration Settings -> General) for each project, you can set the output directory. Change it for every configuration/platform of every project to e.g. $(SolutionDir)$(Platform)\$(Configuration)\ (or anything else that resolves to the same location for each project).
The alternatives are to either add a post-build step to copy files around via command, or to change your DLL resolution mechanism and use delay loading code that resolves referenced DLLs "manually".
I've been encountering a strange bug in Visual Studio 2010 for some time now.
I have a solution consisting of a project which compiles to a static library, and another project which is really simple but depends on this library.
Sometimes, in the last days extremely frequent, after Rebuilding the Solution or just compiling it with 1-3 changed source files, I get the following error:
2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
Where compiling thelibrary.lib was a success without any errors or warnings.
I have tried cleaning the solution, but that doesn't always work.
What is wrong here?
In Linker, general, additional library directories, add the directory to the .dll or .libs you have included in Linker, Input.
It does not work if you put this in VC++ Directories, Library Directories.
I can see only 1 things happening here:
You did't set properly dependences to thelibrary.lib in your project meaning that thelibrary.lib is built in the wrong order (Or in the same time if you have more then 1 CPU build configuration, which can also explain randomness of the error). ( You can change the project dependences in: Menu->Project->Project Dependencies )
Go to:
Project properties -> Linker -> General -> Link Library Dependencies set No.
I recently hit the same error. Some digging brought up this:
http://support.microsoft.com/kb/815645
Basically, if you have spaces in the path of the .lib, that's bad. Don't know if that's what's happening for you, but seems reasonably possible.
The fix is either 1) put the lib reference in "quotes", or 2) add the lib's path to your Library Directories (Configuration Properties >> VC++ Directories).
I had the same issue in both VS 2010 and VS 2012.
On my system the first static lib was built and then got immediately deleted when the main project started building.
The problem is the common intermediate folder for several projects. Just assign separate intermediate folder for each project.
Read more on this here
I solved it with the following:
Go to View-> Property Pages -> Configuration Properties -> Linker -> Input
Under additional dependencies add the thelibrary.lib. Don't use any quotations.
I had a similar problem in that I was getting LINK1181 errors on the .OBJ file that was part of the project itself (and there were only 2 .cxx files in the entire project).
Initially I had setup the project to generate an .EXE in Visual Studio, and then in the
Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type, I changed the .EXE to .DLL. Suspecting that somehow Visual Studio 2008 was getting confused, I recreated the entire solution from scratch using .DLL mode right from the start. Problem went away after that. I imagine if you manually picked your way through the .vcproj and other related files you could figure out how to fix things without starting from scratch (but my program consisted of two .cpp files so it was easier to start over).
I'm stumbling into the same issue. For me it seems to be caused by having 2 projects with the same name, one depending on the other.
For example, I have one project named Foo which produces Foo.lib. I then have another project that's also named Foo which produces Foo.exe and links in Foo.lib.
I watched the file activity w/ Process Monitor. What seems to be happening is Foo(lib) is built first--which is proper because Foo(exe) is marked as depending on Foo(lib). This is all fine and builds successfully, and is placed in the output directory--$(OutDir)$(TargetName)$(TargetExt). Then Foo(exe) is triggered to rebuild. Well, a rebuild is a clean followed by a build. It seems like the 'clean' stage of Foo.exe is deleting Foo.lib from the output directory. This also explains why a subsequent 'build' works--that doesn't delete output files.
A bug in VS I guess.
Unfortunately I don't have a solution to the problem as it involves Rebuild. A workaround is to manually issue Clean, and then Build.
I don't know why, but changing the Linker->Input->Additional Dependencies reference from "dxguid.lib" to "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86\dxguid.lib" (in my case) was the only thing that worked.
Maybe you have a hardware problem.
I had the same problem on my old system (AMD 1800 MHz CPU ,1GB RAM ,Windows 7 Ultimate) ,until I changed the 2x 512 MB RAM to 2x 1GB RAM. Haven't had any problems since. Also other (minor) problems disappeared. Guess those two 512 MB modules didn't like each other that much ,because 2x 512 MB + 1GB or 1x 512 MB + 2x 1GB didn't work properly either.
For me the problem was a wrong include directory. I have no idea why this caused the error with the seemingly missing lib as the include directory only contains the header files. And the library directory had the correct path set.
You can also fix the spaces-in-path problem by specifying the library path in DOS "8.3" format.
To get the 8.3 form, do (at the command line):
DIR /AD /X
recursively through every level of the directories.
I had the same problem. Solved it by defining a macro OBJECTS that contains all the linker objects e.g.:
OBJECTS = target.exe kernel32.lib mylib.lib (etc)
And then specifying $(OBJECTS) on the linker's command line.
I don't use Visual Studio though, just nmake and a .MAK file
I had the same error when running lib.exe from cmd on Windows with a long argument list. apparently cmd.exe has max line length of about 8K characters, which resulted that the filenames at the end of this threshold got changed, thus resulting in bad filename error.
my solution was to trim the line. I removed all paths from filenames and added single path using /LIBPATH option. for example:
/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
I found a different solution for this...
Actually, I missed comma separator between two library paths. After adding common it worked for me.
Go to: Project properties -> Linker -> General -> Link Library Dependencies
At this path make sure the path of the library is correct.
Previous Code (With Bug - because I forgot to separate two lib paths with comma):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Code after fix (Just separate libraries with comma):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Hope this will help you.
In my case I had the library installed using NuGet package (cpprestsdk) AND I falsely added the lib to the Additional Dependancies in the Linker settings. It turns out, the package does it all for you.
The linker then tried to find the library in the library path and of course could not find it.
After removing the library from the Additional Dependencies everything compiled and linked fine.
Not quite the answer to OP's question as I am using CMake with Visual Studio as a generator but I personally also just encountered the same issue (I am using Visual Studio toolchain, but not the IDE to build stuff).
My fix was target linking the directory of the directory of the libraries (I had a few) before target linking the library.
//Works
target_link_directories(MyExe PRIVATE /out/of/scope/path/to/lib)
foreach(X IN LISTS LIBSLISTNAMES)
target_link_libraries(MyExe ${X})
endforeach()
//Throws cannot open cannot open input file error
foreach(X IN LISTS LIBSLISTNAMES)
target_link_libraries(MyExe /out/of/scope/path/to/lib/${X})
endforeach()
Not sure what is happening under the hood, but maybe VS IDE has equivalent setting somewhere?
I've also experienced this problem. For me the dependencies were properly set, but one of the projects in my solution wasn't selected for building in the configuration (VS 2022 pro).
I eventually figured out thanks to output in Build -> Clean Solution that mentioned one of the project in dependency chain being disabled. Interesingly enough, when trying to build the disabled project it wouldd not properly build its dependencies.
In the solution were two projects A and B. Building B requires A.lib, and somewhere along the line, the solution was cleaned.
Later, for testing purposes it was desired to build B alone, and the error was mistakenly taken as
cannot open input file 'B.lib'
instead of what it actually was
cannot open input file 'A.lib'
So burning the candles at both ends in order to comprehend why the project B build process would delete its own library!
I created a bin directory at the project_dir level, then created a release/debug directory inside the bin folder, which solved the problem for me.