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.
Related
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 have a VisualStudio (2015 in case it matters) solution which has a C++ project compiled as a DLL, and that DLL is then used via DllImport in a C# Windows Forms project that is my executable. Let's call this executable ExeA. Because this ExeA needs my DLL in the same directory as the build location for ExeA.exe, and because I build for multiple platforms, in both Debug and Release flavors, configured the C++ project settings to have
<OutDir>$(SolutionDir)ExeA\bin\$(Platform)\$(Configuration)\</OutDir>
This makes sure that whichever way I build my executable project, the DLL is always delivered to the correct folder. However, this hard-codes ExeA name into the C++ project settings.
I am now adding a secondary C# executable project, let's call it ExeB, which must also use this DLL. Ideally, I would modify my C++ project settings to pick up the name of the target executable project from some Visual Studio variable. I looked here, but could not find a variable that represents the name of the project within a solution which is currently set as the "executable" project. Does anyone have any suggestions?
I have written an application in Visual Studio 2013 that relies on a DLL called WSTP32i1.dll. Both the dll and its associated .lib file are included in the project and it compiles and builds without error. However, when I run it, I get this:
Putting a copy of the DLL in the application folder doesn't help. When I check the Solution Explorer, the DLL appears to be marked "Does not participate in build," which seems wrong but I'm not sure what to change it to.
Any suggestions?
Solution Explorer tree contains source files (cpp, h, rc etc.) used to build executables. Item Type property defines how this file will be processed. DLL is not a valid source file and IDE does not know how to process it. That is why it "Does not participate".
The standard (and the easest) way to link import library is to add reference to DLL project in Common Properties / References page of application project. By default, all DLL and EXE files of your solution are built in the same $(SolutionDir)$(Configuration) directory, so everything is ready to use without any adjustments and post-build events.
If your DLL is built in another solution, make sure that it is placed in the same folder as EXE file, or DLL's folder is specified in PATH environment variable.
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 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.