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".
Related
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 am working on a project that involves making a dynamic link library, so I want to test it in a console app in Visual Studio.
The DLL is also made in Visual Studio, it doesn't have much, just a few functions in it. I'm not sure if I'm just supposed to include the librarys header in the include directories panel in Properties, or do something else
A lot of people say I'm supposed to add its corresponding .lib file in the Library or Reference directory, but I'm not sure that VS generates a .lib file alongside the DLL. I'm using VS 2015.
I don't have VS in front of me this very moment, but these should be the general steps to set it up:
Properties->Linker->Input: your.lib
Properties->Linker->Additional Library Directories: ../your/bin
Properties->General->Compiler->Additional Include Directories: ../your/include
To build your app, the DLL's API headers must be in the include for the compile-time, it's LIB files in the bin for the link-time. Once you have your app EXE, all you need is the DLL to be in the same folder as your EXE when it executes.
You might also want to add the dll project and the app project into a common solution in VS and add (right click) Project Dependency from the app to the dll. This ensures correct order of building, assuming you are going to build the dll at all.
You can also do what I did.
You can create a Libs directory inside of your Solution directory.
You can then place your .DLL files inside of the Libs directory or some sub-directory inside of Libs
In my case, I added the entire SFML-2.3.2 directory in there, which included the source-code, .lib files, and .dll files.
I did link up what I could in the project properties, but I used Visual Studio's macros to fill in the path name to the Solution directory. Just in case I wanted to put this in version control and work on it from multiple machines.
Then I opened up the Project's Property Page.
Within the property page, I went to Build Events -> Post-Build Event -> Command Line
Within the Command Line, you can add a copy command that will copy any needed files into the same directory as the executable that will need them.
In my case I used: copy "$(SolutionDir)Libs\SFML-2.3.2\bin\*" "$(TargetDir)"
I could have written multiple commands to copy just the individual files that I needed, but I had spent a good three hours trying to get SFML to work without actually installing it.
I set up a c++ project to use a DLL in visual studio. The library had .h .lib and .dll files. The program compiles and runs, and successfully uses the library. The DLL was put in the root directory of the source, not the output directory. When I build, I expected the DLL to be copied form the source to the output directory, but it's not. All I see in the output directory is 3 files of type, application, incremental linker file, and program debug database.
Maybe I'm wrong but I thought that the DLL needed to be in the same folder as the executable in the output directory. So what's going on?
This is something I had difficulty finding as well, but VS does not copy the .dll's for you. You have to tell it to by creating a Post-Build event. Check out the link on XCOPY:
https://support.microsoft.com/en-us/kb/240268
I needed to copy some dll's to my target directory (the build directory) so used the following in a Post-Build event in my project settings:
xcopy $(ProjectDir)openal32.dll $(TargetDir) /Y /D
Just replace "openal32.dll" with whatever dll you need to copy and make a new build event for each dll you need copied to the target (build) directory.
/Y suppresses prompting to confirm overwrite
/D instructs the compiler to only copy if it's a newer version of the dll on this build.
When I build, I expected the DLL to be copied form the source to the
output directory, but it's not.
Maybe I'm wrong but I thought that the DLL needed to be in the same
folder as the executable in the output directory. So what's going on?
First, DLL's are not part of the build process, that's one reason why Visual Studio doesn't do anything with your DLL.
Having said that, another reason why Visual Studio shouldn't automatically copy over the DLL to your executable directory is that Visual Studio doesn't and cannot assume this is where you want your DLL placed.
It can't assume this because you may want your DLL to be placed in one of the directories that will be found by the Windows OS when it is time to load the DLL. See this link:
Dynamic Link Library Search Order
What if you are testing your app to see if it will load the DLL correctly if it is placed in a certain directory on your PATH? How will you do that if Visual Studio were to always copy the DLL to your executable directory?
Another scenario: What if your program uses LoadLibrary and wants to test if the program behaves correctly if the DLL is not found?
As the other answer suggested, that's why you have to make the concerted effort of telling Visual Studio what to do in the post build event. Also, even after applying the post build event, Visual Studio still knows absolutely nothing about your DLL -- all it sees is a copy or xcopy command.
I'm using Visual Studio 2008.
I have a solution with two projects. One builds a DLL, which is my "production code". The other builds a console app exe, which is my unit test suite.
For my unit test project, I have listed as linker inputs the names of the source modules from the DLL. I.e., I have a DLLMain.cpp in the DLL project, and a linker input "DLLMain" in the exe project. This allows the exe to link with the obj files produced by the DLL project, preventing recompilation of those modules just for the unit tests. (Saves a lot of build time.)
THE PROBLEM IS that because the exe is produced later than the obj's, and by a different project, its timestamp is always newer than the obj's. So when you try to run or debug, it ALWAYS says the exe project is out of date and needs to be rebuilt.
Is there some way I can configure the exe project to ignore the timestamps? Or is there some other, perhaps more general, solution I'm not seeing here?
Seems like you are creating foo.obj in the DLL's project, linking foo.obj in the DLL project to produce the DLL, and then linking foo.obj to your EXE project without first recompiling it.
I have never done this before, but first thing I would check is to make sure the Intermediate Directory settings are the same for both the EXE project and the DLL project.
Go to the project that is not needed for unit testing
Right click on it and press Properties
Click on Configuration manager
Add a new configuration using the first drop down list
Click ok
Select that configuration in the window that is now focused
then in configuration properties set "Excluded From Build" to yes