Create DLL from unmanaged C++ - c++

I currently have a console application written in unmanaged C++, the source code consists of an entry-point main and some other functions. I need to create a DLL from this code so that I can use it from other projects, specifically from managed C++. (Another question: would I have to write a wrapper class for this purpose?)
As I know next to nothing of managed/unmanaged C++ and creating DLLs, I followed this tutorial and managed to get a simple Hello World DLL up and running by using only VS2010 (no CMake).
However, this project of mine has a lot of dependencies (e.g. Point Cloud Library), and so I normally use CMake to generate the Visual Studio 2010 solution that then builds into an executable, as described in the PCL Tutorial. How can I use CMake to build a VS2010 project that will build into a DLL?
To summarise my problem:
I have a project of unmanaged C++ code that needs a lot of dependencies.
I want to create a DLL from this code that can be called from managed C++.
Extra information:
Windows 7, Visual Studio 2010 Ultimate, CMake 2.8.10.2
EDIT:
I used CMake with your line changed, and it worked as expected. This is what I have since added to my header file, am I on the right track?
MyCode.h
#ifdef MyLib_EXPORTS
#define API_DECL __declspec( dllexport )
#else
#define API_DECL __declspec( dllimport )
#include <iostream>
#include <pcl/...>
etc...
API_DECL void myFirstFunction();
API_DECL void mySecondFunction();
#endif
MyCode.cpp: I have not made any changes to the source file, should I make any?

Unfortunately, I cannot help you with the managed code part, but this is how you create a DLL in CMake:
First of all, instead of using
`ADD_EXECUTABLE( YourLib SHARED yourclass.cpp yourclass.h )`
in your CMakeLists.txt, use
`ADD_LIBRARY( YourLib SHARED yourclass.cpp yourclass.h )`
This will configure the solution to create a DLL rather than an executable.
However, to be able to use this DLL with your projects, you need to export the symbols you want to use. To do this, you need to add __declspec( dllexport ) to your class and/or function declarations. Building the library will then yield two files, a .dll and a .lib. The latter one is the so-called import library that you need when you want to use this library in your other projects. The .dll will be required at runtime.
However: When you want to use your library, you need to use __declspec( dllimport) (rather than dllexport). To avoid using two header files, the usual way to do this is to use the preprocessor. CMake actually helps you by providing a YourLibrary_EXPORTS define in your library project.
To summarize:
#ifndef YOUR_CLASS_H
#define YOUR_CLASS_H
#ifdef YourLib_EXPORTS
#define API_DECL __declspec( dllexport )
#else
#define API_DECL __declspec( dllimport )
#endif
class APIDECL YourClass {
void foo();
void bar();
};
#endif // YOUR_CLASS_H
EDIT:
If you want to be able to use those functions from C (and languages that are able to use C functions) you should wrap your declarations with extern "C" {
extern "C" {
API_DECL void myFirstFunction();
API_DECL void mySecondFunction();
}

Related

Compiler C2491 error: solution requires loss of data? [duplicate]

I am working on a C++ (VS2017) project that uses a protobuf type I created.
However, this project requires a .dll of said protobuf type. The __declspec( dllexport ) in each class declaration are not there by default, and I read online that they can be added by generating the protobuf object with this command line:
--cpp_out=dllexport_decl=MY_EXPORT_MACRO:output/directory
No one has explained what MY_EXPORT_MACRO is or how to define it. When I first generated my protobuf objects I used the most basic line and it worked:
protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/my_file.proto
What and where is MY_EXPORT_MACRO and/or is there another way to make my protobuf files .dll compatible?
You know about __declspec( dllimport ) also, correct? What's the easiest way to use the same type definition while building the DLL (with dllexport annotations) and in DLL clients (with dllimport annotations)?
Having a macro to switch the annotation is an extremely common practice in Win32 DLL development of all sorts, not just for protobuf DLLs.
Usually the definition runs like this:
#if BUILD_DLLX
# define DLLX_API __declspec(dllexport)
#else
# pragma comment('lib', 'dllx.lib')
# define DLLX_API __declspec(dllimport)
#endif
And then you would use --cpp_out=dllexport_decl=DLLX_API:$DST_DIR so that the generated header files have DLLX_API inserted in the right places. Then build the DLL with /DBUILD_DLLX so it exports the types and functions.
Consumers of the DLL can #include the exact same header file, and with no /DBUILD_DLLX in their project configuration, they'll end up with imports.

How does __declspec exactly work? [duplicate]

I had a question about DLL building / linking in Visual Studio 2005 and later. Basically my understanding and experience is this:
To build a DLL, I specify the project properties to build a DLL, and then I but __declspec(dllexport) in front of any functions or members that I want to publically expose from the DLL. Building the project will result in a DLL, a Lib, and a header file that can be deployed as say an API or something.
On the other end, to have your other compiled executable application dynamically link to the DLL and use its functions, you simply need to have your executable project include the header files and link with the small lib file that was created when the DLL was built. As long and the compiled application can find the DLL, everything will work.
That has been my experience and that is also how the Microsoft DLL building tutorial described everything on MSDN. I am wondering: is this standard practice? When would you ever need to use __declspec(dllimport) anywhere? Am I missing something?
Thanks!
Yes you would use __declspec(dllimport) and you generally have a macro that controls whether a source file either exports (if it's part of your DLL) or imports (if it's part of the using-executable) symbols.
In your DLL you can set a manifest constant to the build settings of some sort, say 'BUILDING_MY_DLL' and then create the macro like this within your header file:
#ifdef BUILDING_MY_DLL
#define MY_DLL_EXPORT __declspec(dllexport)
#else
#define MY_DLL_EXPORT __declspec(dllimport)
#endif
and then decorate your exported functions like this:
MY_DLL_EXPORT int func(int y);
You can also export entire classes this way too:
class MY_DLL_EXPORT InterestingClass
{
...
};

How to Expose C Static Library to .Net?

What are the steps to expose C++ functions to C and .Net? I want to use the same function names in C++, C and .Net for 32-bit and 64-bit builds.
I'm posting this question and answer because I haven't found these techniques documented anywhere.
The steps are:
Expose C++ functions as a C static library (.lib).
Use #pragma statements to project the lib's functions into a DLL.
Use .Net's DllImport attribute to expose the DLL's functions.
For an example, see this github project.
Step 1. Create a static library project. Create a C++ file that exposes each function as a C function.
extern "C" {
void vfunc(void) { return; }
int ifunc(int i) { return i; }
}
Step 2. Create a DLL project. Specify the static library as an "Additional Dependency". Create a C file and put #pragma statements to project each static lib function into the .DLL. You'll need to define two #pragmas, one for 32-bit and another for 64-bit. The difference being that 32-bit requires a leading underscore before the function name. No code necessary, just #pragmas.
#ifdef _M_X64
#define Alias(func) comment(linker, "/export:" func "=" func)
#else
#define Alias(func) comment(linker, "/export:" func "=_" func)
#endif
#pragma Alias("vfunc")
#pragma Alias("ifunc")
Step 3. Create a .Net project. Use DllImport attribute to expose each function.
class Program
{
[DllImport("c-dll.dll")]
extern static void vfunc();
[DllImport("c-dll.dll")]
extern static void ifunc();
static void Main(string[] args)
{
vfunc();
int i = ifunc(1);
}
}
While coding is straightforward using these techniques, you'll need to do quite a bit of editing of solution and project files.
Set the solution's correct build order. The DLL will depend on the static library. The .Net projects will depend on the DLL.
Manually edit the DLL project file to build the 32-bit and 64-bit DLLs into separate directories (e.g. Win32\Debug, x64\Debug).
Manually edit the .Net project files to create sections for combinations of x86/x64 and Debug/Release (4 total). DO NOT USE AnyCPU. DllImport WILL NOT WORK WITH AnyCPU. USE ONLY x86/x64.
Manually edit the .Net project file output path to be the same Win32/x64 directories as above. This will allow DllImport to find the DLL since DLL/EXE share the same directory. Optionally you can put the DLL into a discoverable directory or put a path in DllImport -- but that's problematic when you are using two DLLs (32/64).

When is __declspec(dllimport) used? [duplicate]

I had a question about DLL building / linking in Visual Studio 2005 and later. Basically my understanding and experience is this:
To build a DLL, I specify the project properties to build a DLL, and then I but __declspec(dllexport) in front of any functions or members that I want to publically expose from the DLL. Building the project will result in a DLL, a Lib, and a header file that can be deployed as say an API or something.
On the other end, to have your other compiled executable application dynamically link to the DLL and use its functions, you simply need to have your executable project include the header files and link with the small lib file that was created when the DLL was built. As long and the compiled application can find the DLL, everything will work.
That has been my experience and that is also how the Microsoft DLL building tutorial described everything on MSDN. I am wondering: is this standard practice? When would you ever need to use __declspec(dllimport) anywhere? Am I missing something?
Thanks!
Yes you would use __declspec(dllimport) and you generally have a macro that controls whether a source file either exports (if it's part of your DLL) or imports (if it's part of the using-executable) symbols.
In your DLL you can set a manifest constant to the build settings of some sort, say 'BUILDING_MY_DLL' and then create the macro like this within your header file:
#ifdef BUILDING_MY_DLL
#define MY_DLL_EXPORT __declspec(dllexport)
#else
#define MY_DLL_EXPORT __declspec(dllimport)
#endif
and then decorate your exported functions like this:
MY_DLL_EXPORT int func(int y);
You can also export entire classes this way too:
class MY_DLL_EXPORT InterestingClass
{
...
};

how we can convert a project written en c++ to dll file?

I have a project written en c++ in which i use tesseract and opencv libraries.
the project contain one function which return an Int ant it has as parameter sting an int
int image_blanche(string nom_img,double k);
My question how can i convert it to dll file to use it in an other .net project
Add a header file (e.g. "Defines.h") containing:
#pragma once
#ifdef COREDLL_EXPORTS
#define COREDLL_API __declspec(dllexport)
#else
#define COREDLL_API __declspec(dllimport)
#endif
Your function should then be defined in a header like this:
#include "Defines.h"
extern "C"
{
COREDLL_API int image_blanche(char const* nom_img,double k);
};
...and implemented in a source file.
Compile that Project with COREDLL_EXPORTS defined as a DLL Project and use the dll in another project.
When building the DLL having COREDLL_EXPORTS defined you basically produce (=export) the symbols and place them in the DLL. When using the DLL in another project not having COREDLL_EXPORTS defined, you consuming/reading (=import) the symbols from the DLL.
Here is a good explanation of how you can then invoke the function from the DLL: Dynamic Invoke C++ DLL function in C#
Update: As MSalters correctly pointed out, using C-Style datatypes should be considered, as it plays friendly across DLL bounds. I changed the string parameter to use a character array instead.