I have a Visual C++ DLL project (just a project, without parent solution) and need to build the DLL.
Build command doesn't generate any error messages. In the Debug folder there is mylibrary.lib, but no mylibrary.dll.
I looked at Visual Studio 2010 C++ DLL project - No output DLL file!, but my case differs from that question. In the build output, there is no message like
MFCInterop.vcxproj -> C:\temp\sotest\Debug\MFCInterop.dll
only
MFCInterop.vcxproj -> C:\temp\sotest\Debug\MFCInterop.lib
What can I do in order to generate the DLL file?
I may be that the dll generated but not in the Debug folder.You should set the output directory for the project.For this go to
project property--->General--->Output Directory--->.\Debug
It may happen if your DLL does not expose anything.
Normally public API classes of your DLL should be exposed using following construction:
#ifdef YOUR_DLL_EXPORTS
#define YOUR_API __declspec(dllexport)
#else
#define YOUR_API __declspec(dllimport)
#endif
class YOUR_API ClassToExpose {};
Then you have to define YOUR_DLL_EXPORTS inside DLL project.
If you don't have exposed stuff DLL is not generated. I hope this helps.
Related
I have a legacy project that used to be build in Visual C++ 2005 Express, and it depends on a certain third party DLL. As far as I can tell it doesn't come with a lib or header file.
The project compiles fine in Visual C++ 2005, here is a screenshot showing the DLL visible and browsable in the object explorer. The code can also use it without #include or anything like that, which is pretty weird.
Importing the project into Visual Studio 2019 works as well, the code can still use the DLL and it is listed under both the dependencies and the references:
I now want to achieve the same thing in a new project, but I cannot figure out how to register the DLL as a dependency. Things I found online and tried:
"Just include the header or lib file" doesn't work, I don't have one
LoadLibrary() and GetProcAddress() are awfully contrived and don't seem necessary because it's clearly possible without.
Create your own lib file doesn't work either, dumpbin doesn't show any symbols for my DLL: image
How do I register the DLL as a dependency? And where does Visual C++ 2005 get the list of methods in the DLL from is the first place?
We have a visual studio project to produce a DLL file, and we've now refactored all the sources out into 3 separate projects which produce static libs. This leaves behind the .def file, and some pre and post-build actions related to the dll itself in this project. We'd like to keep the generation of the DLL and all the additional behavior separate from the other projects if we can.
Unfortunately, now when we try to "build" this project, it does not produce a DLL anymore (presumably because there are no sources that reference any of the libs).
I've added /WHOLEARCHIVE:themainstaticlib, but that doesn't seem to be enough.
If it's possible to have a Visual Studio project that JUST creates a DLL from static libs and a def file (and a /wholearchive directive), can someone please let me know how?
I managed to set up build project in dll mode and in library mode but not together:
for build in dll:
project->properties->Configuration Type: Dynamic Library (.dll)
project->properties->Target Extension: .dll
for build in library:
project->properties->Configuration Type: Static library (.lib)
project->properties->Target Extension: .lib
it is possible to build both of them together?
Yes, you can have single project that can be used for .dll and .lib.
Steps to be followed:
Visual Studio will provide you Debug and Release solution
configurations. Create custom configurations for lib and dll (i.e.
lib-release, dll-release).
For each configuration set different project type and set export
symbols. i.e. for lib-release define LIB_CONFIG and don't set it for
dll-release.
In code file use LIB_CONFIG with #IFDEF to include/exclude project
type specific code. IF some part of code is lib specific the add it
in #ifdef LIB_CONFIG...#endif, and if it is dll specific add it in
#ifndef LIB_CONFIG...#endif.
Compile project after changing Active solution configuration. i.e.
change to lib-release, if you want to have .lib file.
I hope this will help you. Please let me know your feedback.
During creation of new project in Visual Studio, make sure you check on "Export Symbols"
No. You must have two projects in your solution (using the same source files). Don't forget to have different names for your 2 .lib files.
EDIT: use some trick to not include a DllMain function in your static lib (either some #ifdef, or a separate file not added to the static project)
I've been told several times that I should consider splitting parts of my app into separate DLLs (to speed up linking, etc.) and am trying to figure out how that works.
I understand that I need to add __declspec(dllexport) to every header file declaration that I plan on using. That seems tedious, but it's doable.
How do I get the app + DLLs to run? In a simple test project, the only way I found that works is to manually copy the DLL from the DLL project's build output directory to the exe project's build output directory. I know I can set up a post-build step to do this, but I'd expect the IDE to have some way to automate having an app project use a DLL project when they're part of the same project group.
How do I debug the app + DLLs? I see where I can specify a host application for a DLL under Project -> Options -> Debugger, but so far, I've only been able to figure out how to debug one project at a time. I'd really like to be able to set breakpoints anywhere in the codebase and single-step through anywhere in the codebase (instead of being stopped at project boundaries), and I can't figure out how to do that.
I understand that I need to add __declspec(dllexport) to every header
file declaration that I plan on using. That seems tedious, but it's
doable.
What you should do is create a #define in your DLL's header file that maps to dllexport when the header is compiled by the DLL project, and maps to dllimport when compiling in other projects. For example:
#ifndef MyDLLH
#define MyDLLH
#ifdef _BUILDING_DLL_
#define MY_EXPORT __declspec(dllexport)
#else
#define MY_EXPORT __declspec(dllimport)
#endif
#ifdef __cplusplus
extern "C" {
#endif
MY_EXPORT type callingconvention SomeFunc(parameters);
#ifdef __cplusplus
}
#endif
#endif
Then you can define _BUILDING_DLL_ in your DLL project only, either in the Conditionals list of the Project Options, or in your code above any #include statements for the header file, eg:
#define _BUILDING_DLL_
#include "MyDll.h"
How do I get the app + DLLs to run?
The DLL project generates a .lib file that is used for static linking to the DLL's exported functions. You can add that .lib file to your EXE project and then call the DLL functions like any other function call. Or you can dynamically load the DLL functions at runtime using the Win32 API LoadLibrary() and GetProcAddress() functions, in which case you do not use the .lib file at all.
In a simple test project, the only way I found that works is to
manually copy the DLL from the DLL project's build output directory to
the exe project's build output directory.
The EXE's folder is the first place the OS looks for the DLL, but it is not the only place the OS can look. MSDN documents how DLL's are located at runtime:
Dynamic-Link Library Search Order
I know I can set up a post-build step to do this, but I'd expect the
IDE to have some way to automate having an app project use a DLL
project when they're part of the same project group.
Just being part of the same project group is not enough. The projects are compiled independantly of each other. However, you can set the DLL project as a dependancy of the EXE project (or just make sure the DLL projct is higher up on the build order then the EXE project) so the DLL is compiled first, then use the DLL's PostBuild events to move the compiled .lib and .dll binaries where needed, and lastly add the DLL's compiled .lib file to the EXE project so the DLL is used at runtime.
How do I debug the app + DLLs?
You have a couple of choices:
To debug just the DLL by itself, load the DLL project into the IDE, go into the Run parameters, and set the compiled EXE at the Host application. You can then Run the DLL project as if it were an EXE project. The EXE will be executed and the debugger will attach to the DLL once it is loaded into memory.
To debug both projects at the same time, load the EXE project into the IDE instead, and make sure the DLL's source folder is specified in the Debug Souce path of the Project Options. You can then run the EXE project normally, step into the DLL functions when they are called, set breakpoints in the DLL's source, etc.
We have a DLL, built with MS Visual Studio 2010, in release mode. We provide this DLL to different customers, along with a .lib file. The functions in the DLL are exported with:
extern "C" __declspec(dllexport) int analyze(int id);
Our customers have two applications that makes use of this DLL. Both of these applications import the DLL functions using:
extern "C" __declspec(dllimport) int analyze(int id);
One of these applications is built with MS Visual Studio 2010. This application can be built successfully in both debug and release modes.
The other application must unfortunately use MS Visual Studio 2005 as its build environment. In this application, the release build can be built successfully, however, when we try to build in debug mode, we get linker errors:
LNK2019: unresolved external symbol __imp_analyze referenced in function "void __cdecl process(char const *,char const *)" (?process##ABCERFG0#Z)
Can someone help me understand what we are missing here? Are we exporting the functions in a manner that is not portable across compilers? What's the solution?
Regards,
The .obj file format is highly conserved between VS2005 and VS2010. This should not be a problem, especially since it is a simple non-mangled symbol reference. And especially not when it works in the Release configuration but not in Debug. A simple explanation is always better than a convoluted one: your customer simply forgot to add your .lib file to the linker's Additional Dependencies setting.
Beware that the setting change needs to be made for both configurations, use the "Configuration" combo in the upper left corner of the dialog.
You can help your customer fall into the pit of success by using #pragma comment(lib, "mumble.lib") in your .h file.