Here's a minimalistic sample of a native wrapper to make a .NET managed library accessible to native C++ code, posted in response to a thread in another forum section.
The demo solution contains three projects, one representing each the managed library to be made accessible, the wrapper DLL and the native client app. Here are the relevant source files, ordered from low level upward:
Code:
// ManagedLib.h
#pragma once
namespace ManagedLib
{
public ref class ManagedClass
{
public:
static void SayHello();
};
}
Code:
// ManagedLib.cpp
#include "stdafx.h"
#include "ManagedLib.h"
using namespace System;
using namespace ManagedLib;
void ManagedClass::SayHello()
{
Console::WriteLine("Hello from the managed world!");
Console::Out->Flush();
}
// NativeWrapper.cpp
#include "stdafx.h"
#define BUILDING_WRAPPER_DLL
#include "NativeWrapper.h"
// Must be compiled with CLR support.
//
// In the demo solution, this project has a project reference to ManagedLib. In a real-life
// scenario with a 3rd-party .NET library DLL, that would either be an assembly reference to
// that DLL or simply a #using directive (note the #).
//
// No need to #include ManagedLib.h: The prototype information is implicitly imported by
// referencing the .NET library DLL.
void WINAPI NativeHelloWrapper()
{
ManagedLib::ManagedClass::SayHello();
}
Code:
// NativeWrapperDemo.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//
#include "stdafx.h"
#include <iostream>
#include <Windows.h>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
HMODULE hdll = LoadLibrary(_T("NativeWrapper.dll"));
_ASSERT(hdll);
FARPROC NativeHelloWrapper = GetProcAddress(hdll, "_NativeHelloWrapper@0");
_ASSERT(NativeHelloWrapper);
cout << "Have a nice native program run! :)" << endl;
NativeHelloWrapper();
cout << "Back in the native world." << endl;
return 0;
}
Actually, the term "native wrapper" is somewhat inaccurate: The wrapper DLL isn't strictly native, it rather is a mixed-mode DLL containing both native and managed code. However, the same inaccuracy usually applies to the to the term "managed wrapper". The word before "wrapper" rather denotes the type of interface exposed.
Of course there's plenty of room left for more in-depth discussions about performance considerations and such, I'm just too tired to start that right now. At any rate, I think, while I wouldn't really bet on that the wrapper approach beats a COM-based approach which bypasses the wrapper stage hands-down in terms of performance, I'd say at least it's more convenient. And it most probably isn't significantly inferior compared to the COM approach.
Last edited by Eri523; March 19th, 2013 at 12:35 PM.
Reason: Added a link back to the originating thread
I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.
This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.