Can't get DLL to work on Visual Studio - c++

I've been following the tutorial from msdn and it just doesn't work.
First problem I have is that sometimes the .dll and .lib aren't built. Instead I only get .objs. Whenever I build the .dll project, it gives me a popup asking to "please specify the name of the executable file to be used for the debug session". I was told to change my startup project to one with a main function, but then the .dll doesn't get built. This happens both using the default VS configuration and simply adding some lines or following the step-by-step guide at msdn.
When the .dll and .obj are built - God knows how - I can't get them to be recognized. I've tried putting them and the .h in the project folder, but then I get an error about the .dll function being undefined. Following the msdn link, at one point it says:
To use the math routines that were created in the dynamic link library,
you must reference the library. To do
this, select References… from the
Project menu. On the Property Pages
dialog box, expand the Common
Properties node, select References,
and then select the Add New Reference…
button. For more information about the
References… dialog box, see Framework
and References, Common Properties,
Property Pages Dialog
Box.
The Add Reference dialog box is displayed. This dialog lists all the
libraries that you can reference. The
Project tab lists all the projects in
the current solution and any libraries
they contain. On the Projects tab,
select MathFuncsDll.
If I go Project > Test Properties > Common Properties I can only find the subitem "Framework and References". There is no "References..." There is an "Add new Reference..." button, but that doesn't let me add anything. The other button, "Add Path..." doesn't make any difference even when I set it with the directory with the files. The following steps don't work either.
I've also tried to add the name of the file at the Linker, but then it says it couldn't find the .obj file.
I have no idea where to go from here. I been stuck on this for hours and nowhere has a solution for this.
Is there a step-by-step guide anywhere that actually works for VS2008?

firstly your description is mixing managed (.net) things with normal c++ stuff. I assume you are doing normal c++ stuff.
DO you own (I mean have the source; are the author) both the DLL and the calling program? If so you should have 2 VS projects one for the DLL and one for the program. You should set the program as the startup project. This will make the debugger behave correctly
IN order to get the build right you need to make the c++ program depend on the dll project. There is a Project | Project dependies dialog that will do this for you, set the program project to depend on the dll project
If you only own the DLL then you need to go to the project properties | debug and tell it what binary to run to call your DLL.
If this is managed c++ then its a whole different storty

Try to specify Project Dependencies between your DLL project and project of application that uses the DLL.
The References settings are dedicated to .NET projects.

Related

Create MS Visual C++ DLL project out of existing sources

My goal is to compile existing C++ classes (legacy code, stored in a set of *.h files) into a DLL so that it can be further integrated into a C# application.
For that purpose, it seems best to use MS Visual Studio. I have no experience with this environment, so I tried the naive approach found on MSDN and other SO answers:
File | New | Project from existing code
selected Visual C++
selected file location that is base for include references used in those .h files
specified a project name
let the wizard find and add all C++ files below the directory
selected "Use Visual Studio" for build, with project type "Dynamically Linked Library (DLL) project"
checked none of the checkboxes below (ATL, MFC, CLR)
specified . dir in the "Include search paths (/I)" in Debug settings
checked "Same as Debug configuration" in "Release settings"
clicked Finish button
This creates couple of VS files in the directory:
mylibrary.sln
mylibrary.vcxproj
mylibrary.vcxproj.filters
mylibrary.vcxproj.user
With a project created this way, I press F6 or select Build | Rebuild solution from the menu.
Then I expect the build to produce the .dll file somewhere, but it does not appear. Only these files appear:
.vs/mylibrary/v15/.suo
.vs/mylibrary/v15/Browse.VC.db
.vs/mylibrary/v15/Browse.VC.opendb
.vs/mylibrary/v15/ipch/AutoPCH/efad7c74cd39331b/EXAMPLE.ipch
Debug/mylibrary.log
Debug/mylibrary.tlog/mylibrary.lastbuildstate
Next, I decided to try creating a fresh new library project, just to observe the differences to get some hints, but that did not help - there were too many differences, even in the file structure...
My questions are:
is my choice of MS Visual C++ a good one for given purpose?
if so, what am I doing wrong here?
I think your steps are probably correct and I think that the right approach to use the code from a C# application. You definitely can call a C++ library from C# by importing the methods.
You missed only to export the methods that you want to use from your library. try using __declspec(dllexport) with these methods. please check this link:
https://msdn.microsoft.com/en-us/library/a90k134d.aspx.
Also, the output should be at the build folder, not the source code folder
Compiling .h files into libraries is ok, the compiler does not care - however, the UI does.
Still, you can tweak this by directly editing the .vcxproj file.
While doing so, make sure that the <ClCompile> sections contain:
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
Note that you can use commandline for building the DLL project:
"%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe" -target:Clean,Build
(this assumes that your current directory is the one with your .vcxproj)

How to add DLL reference to a c++ project in a native application?

I want to reference some DLLs in my C++ project in VS2013. I searched and found out that it could be done by right-clicking on
project node in solution explorer and select add reference. But when I did as said another window appeared instead of Reference
Manager one. Where is the problem? How can I add my DLLs to my project rather than copying them in same folder with .exe
output?
The reference node also does not appear in solution explorer. I tried show it by clicking "show all files", but it still does
not appear!
EDIT: I edited the title according to drescherjm`s comment.
In a native C++ project in Visual Studio in order to not copy the dlls in the folder of the executable you can right-click on the project -> properties -> Debug -> Enviroment and set the following variable: PATH=<folder where the dll is>;%PATH%
I'm not a great expert of C# but what I know is that in a .NET application, in order to use a component in your application, you need to add a reference to it. For default, the dll is locally copy and deployed with your application; to prevent this, you have to register the dll in the GAC(Global Assembly Cache).

Can't debug c++ project because unable to static library start program *.lib

I'm using a library (Astro.lib) which i've built without problems (i guess this is a release build).
I've also built a project which references the library (it runs as a release exe fine) but i can't debug the project because i get the message 'unable to start program 'Astro.lib'.
If i try to debug the lib then i get the same error, so I guess its something to do with not building for debug my lib but not sure how to modify.
I've tried changing the properties pages using MSDN info but not sure i'm addressing the correct problem. What changes should i make to the properties pages of the library of linking project?
Thanks in advance
I've also built a project which references the library
That's the project you want to debug. You probably just have the wrong project selected as the startup project of your solution. It is marked in bold type in the Solution Explorer window.
Right-click the project that uses the library and select "Set as StartUp Project"
your debug settings are wrong - you're trying to debug the lib, not the exe.
Chances are you've set the library project as the one that is started by the debugger (eg the "startup project" that shows in bold in Visual studio). Change your solution explorer so the main executable project is bold and try again, or right click on it and selecty the appropriate "run in the debugger" option.
Another solution is:
Make sure you have the Solution Explorer view (VIEW->SOLUTION EXPLORER).
Then, right click on SOLUTION at the top, and click EXPLORER.
Under COMMON PROPERTIES->STARTUP PROJECT -> SINGLE STARTUP PROJECT, choose the project that you want VS to execute. Note that this project has the property CONFIGURATION TYPE set as APPLICATION(.EXE). This can b found under the project's properties->CONFIGURATION PROPERTIES->GENERAL.
Hope that helps.

Visual Studio 2008 says "the specified file is an unrecognized or unsupported binary format" when I try to debug

I have a VS2008 solution containing two C++ projects. One is a Win32/console .dll and the other is a tester program to test that dll, also a Win32 console app.
When I build the solution, even with a clean build and with the Debug Command set to the hardcoded path to the executable, trying to debug presents a messagebox saying,
"the specified file is an unrecognized or unsupported binary format".
The program it is trying to execute is the source of tester.cpp.
Can someone suggest a cure? What information may I provide to help solve this problem?
Please make sure that your test application (it should be an executable: .exe) is the one you're running and not the DLL. Set it as the "startup project" for example.
You can do so from within your Solution Explorer by right-clicking the appropriate project and selecting "Set as startup project".
I have a VS2010 solution containing two C++ projects:
one project generates a .lib file and the another project (which contains"main.cpp") is used to test the functionality provided by the .lib file.
for that, I go to the solution explorer, right click '2nd Project' and go to References. when you click "Add new reference", it already contains references to the First Project. Select it.
Now, I need to set the '2nd Project' (which contains "main.cpp") as start-up project so that I can debug the code. for that, again, go to the solution explorer, right click '2nd Project' and go to Set as StartUp Project
The easiest way to solve this issue, is to delete the .suo file and re-build the project.
First, you have to change your folder options, to show hidden files (as the .suo file is generally hidden). If you are not sure how to do it, refer to http://windows.microsoft.com/en-sg/windows/show-hidden-files#show-hidden-files=windows-7
Secondly, browse to the location where the respective Visual Studio Solution file is saved and delete the .suo file. If you need to know more about the .suo files, please refer to http://msdn.microsoft.com/en-us/library/bb165909.aspx
Finally, re-build your project.
This method, generally has solved most of similar issues which occurred to me.
Hope this helps!

Visual Studio 2010 not autolinking static libraries from projects that are dependencies as it should be supposed to

Create a new solution with a C++ console command-line project
Create a new project, a C++ static library
Make the command-line project depend on the library
Make sure "Link Library Dependencies" is turned on in Configuration => Linker => General (it is by default)
Visual Studio will still not link the library.
How can I fix this? It worked in Visual Studio 2008.
This still works, but was changed in VS 2010:
"With VS2010, we stopped supporting project dependencies defining implicit references and we also introduced a new way of defining project dependencies at the project level. Since a project reference and a project dependency are close concepts, both applying to a project, it made sense to have them represented together, in a consistent way, in the project file. As you will see in the snippets below, the only difference between a project reference definition and a project dependency definition consists in metadata that defines the output assembly inclusion/exclusion into/from the main project link command line.
Although we did not remove the “Project Dependencies” dialog, we recommend defining new project dependencies via the “Framework and References” dialog. You need to set the “Reference Assembly Output” property in the property page UI to false for a project dependency and to true for a project reference."
Just right-click on the console project, select "Properties->Common Properties->Framework and References->Add New Reference" and add the static library project; also check that "Link Library Dependencies" is True on the right hand side. Seems to work for debug and release builds. You learn something new every day. ;)
They changed the UI for adding C++ project dependencies in VS2010, but oddly enough, without removing the old UI, or in any way indicating that it no longer works.
To create the dependency in VS2010, you need to use "Add New Reference" (can be found in project properties), and maybe also in the project's right-click menu (don't have VS here to check)
The old "Project Dependencies" dialog is basically broken now.
For MSVC 14 (2015 version) right-click on the project, then "Add->Reference..." and check all the needed dependencies.
Yes, it has changed somewhere between 2010 and 2015 versions. Fun!
And if you are looking to link a project that has resources in it - you need to specify the .res file directly in the list of linker input dependencies (project's properties dialog box) as it doesn't get picked up by the above configuration.
UPDATE
Still the same (new) behavior in MSVC 2017
I believe the old UI (dependencies) affects build order for Visual Studio, when building from within the IDE, for info. The new project configuration system embeds the references in each project file so that you can build from outside the IDE (whereas in previous versions, you could not, because you would not get automatic linking for dependencies, since dependencies were only done at the solution level).
There are also some issues with more complex projects in the new system; specifically, all resulting binary projects need to have explicit references to every dependent library to build correctly, whereas previously they could be effectively inherited from other dependent libraries. Same underlying cause, though.