Visual Studio not finding all source during debugging - c++

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.

Related

How to add a library to my project in a visual studio 2019?

I needed to use zydis library in my VC2019 cpp project.
I have no idea how can I add it to my current project - I downloaded it from github.
There is msvc folder, inside I can find .sln file, some header files and .vcxproj files - what should I do, to just include it into my project and use it?
It can be done by adding a reference to the DLL file.
In Visual Studio, right click on the project, Add Reference. Give the path to the DLL file and add it to the project.
First, I suggest that you could download and install Zydis using the vcpkg dependency manager. The method is easy and convenient.
If you don't use vcpkg, you could follow the steps below.
Open the Zydis.sln in msvc with VS2019.
Copy files in include/Zycore, put them in zydis-master\include\Zycore. Because I find that there should be missing files when I compile Zydis.sln.
Right click Zydis, set Visual Studio 2019(v142) in Properties->General->Platform Toolset.
Compile it, and you will find Zydis.lib in zydis-master\msvc\bin\DebugX64.
Then, you could copy include floder and lib in your program floder.
You could set VS:
Right-click the project, select Properties->Configuration
Properties->C/C++->General, find the Additional Include Directories and set the directory.
Properties -> Configuration Properties -> Linker ->
General, find the Additional library directory in General, and set the lib.
Properties -> Configuration Properties -> Linker -> Input,
find Additional Dependencies and input the lib name.
Besides, you could set five build configurations.

Two different opencv_world builds

I've got 2 builds of OpenCV 4.3 for MS Visual Studio. First one is the prebuilt version from GitHub and the second is the one I've built with CUDA support. They work without issues on their own. I've added the /bin/ folder of both builds to PATH. The problem is that both builds have the lib file named opencv_world430.lib and adding this file to 'Linker' -> 'Input' -> 'Additional Dependencies' causes the linker to find not the DLL I want but the DLL in the folder that is upper at the PATH list.
What I mean is that, when I create a project using non-CUDA build (properly adding include and lib directories to VC++ directories), the DLL with CUDA is linked because its filepath is at a higher position than the one I want.
The solution might be just swapping their places on PATH when I'm working with one but I want to ask if there is an easier way to handle this.
Also: I'm using VS2019 on Windows 10.
I suggest that you could select Properties->Build Event->Post-Build Event->Command Line to copy dll to Debug folder. You could refer to the following example.
copy $(TargetPath) $(TargetDir)..\..\someFolder\myoutput.dll
regasm $(TargetPath)

Adding my DLL into a Visual Studio project in C++

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.

Visual Studio 2012 - error LNK1104: cannot open file 'glew32.lib'

I am having issues compiling a basic openGL program on VS 2012. I get a build error upon compiltation giving me:
1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'
I followed the instructions given to me by the documentation for GLEW.
In your OpenGL project open Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies -> add glew32.lib.
Also you must include #include in your sources; For that add path to your glew folder: Project -> Properties -> Configuration Properies -> General -> VC++ Directories -> Include Directories and Library Directories;
C/C++ Tab -> General -> Additional Include Directories - Add lib folder there
I have also added the glew32.dll onto my Debug folder within my project folder along with the executable. So far I keep getting this error.
If you need any more further clarification of the steps I have done please don't hesitate to ask
In all honesty, there is no real benefit to using the DLL version of glew (short of reduced executable size, but this hardly matters on modern Windows PCs).
It is not like you can simply drop a new version of the DLL into your application and use extensions that you never used before. Likewise, bug fixes are so infrequent/unnecessary with a library that basically just parses the extension spec. files that using the DLL as a means of fixing extension loading bugs in shipped software is also not practical. Statically linking to glew (this means glew32s.lib) makes much more sense in the long run.
The static linking library is also more portable on Windows, it will work with MSVC and MinGW (whereas the DLL library only works with MSVC). Link against glew32s and put that in whatever directory you decided to use for additional library dependencies.
Here is a sample solution configuration for a project I wrote that uses glew. I have established a convention for this particular software where compile-time dependencies are stored under platform/<Subsystem>. Thus, I have glew32s.lib (32-bit) and glew64s.lib (64-bit) in ./Epsilon/platform/OpenGL/glew{32|64}s.lib
Steps to Use Classes form another project (Add header and solver linker errors)
To be able to add the header from another project, first go to "Properties > c++ > General > Additional Include Directories" and add the directory that contains the header. Now you will be able to add the header of the class from the other project, but running the project will still cause Linker Errors.
Add __declspec(dllexport) before the class you are using for the other project. This can be added in the header file of that class. This should be added right before the function or variable or class name. Now you will get a lib file. (if placed in wrong place, you can get this warning: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)
"Properties > Linker > Additional Library Directories". Specify the location of the lib file that is generated.
"Properties > Linker > Input > Additional Dependencies”: Add the name of the lib file.
This sounds like the library has been specified as a dependency, but the linker/additional search path(s) has not been set to include the directory where the library is located.
This may help.
It happened to me under this situation, I clean the solution and build it again, then many errors like LNK1104 occur.
After trying to restart IIS, I build solution successfully without LNK1104 errors. I do not know why, but restarting IIS takes much more time than normal, so I guess something is used by other IIS worker process.
Just give a shot to see if this magic happens on you.
This question is old and marked solved, but I had a similar problem symptoms with a completely different solution. So just in case anyone else stumbles in here:
It appeared that because I had 2 projects under one solution (a dll and an exe), the building order was mixed (from the output window):
1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp
and so on. By the message you copied, it appears you too have more than one project under one solution. One project was looking for the *.lib file that the other build hadn't created yet.
Solution:
Right click on "main" project -> Build Dependencies -> Project Dependencies.. -> Mark which project the main one depends on.

compiled *.lib file visual studio

I have several library project. And I have a solution which including these library project and an application project.
My question is, in linker, should I link the *.lib file from the debug folder of those individual projects or from the debug folder of this solution? If I click rebuild, those library project will be compiled to *.lib and new *.lib file will be generated both in their own solution/Debug folder and the current Debug folder.
My problem is that If I set Liker->General->Additional Library Directories to their individual debug folder and Input->Additional Dependencies to the *.lib files, visual studio will give some random linker error 1104 cant open *.lib file, But it is now the same lib file every time, sometimes is Library1 sometimes is Library2.
If I keep the directories and set the dependencies to all those *.obj files. works just fine.
If I delete the directores and set the dependencies to *.lib files in the current solution debug file by "U:\Source\Applications\CURRENTSOLUTION\Debug\Library1.lib" it works just fine.
So, which is the correct way to way my library?
sometimes is Library1 sometimes is Library2
You probably have a build order problem. It is starting to build your EXE project before the libraries are built. The fix for the existing way you have it is to right-click your EXE project and select "Project Dependencies". Tick the library projects.
But the superior solution is to right-click the EXE project, Properties, Common Properties, Framework and References. Click the Add New Reference button and tick the library projects. That not only takes care of the build order, it also automatically tells the linker to link the .libs. Which now also works in the Release build, your existing solution probably didn't do that yet.