.net - C++/CLI, DllExport and /clr:pure -

here simple native dll:

native.h:

#ifdef building_native_dll #define dllapi __declspec(dllexport) #else #define dllapi __declspec(dllimport) #endif  class dllapi native {     public: void f(); }; 

native.cpp:

#include "native.h"  void native::f() { } 

build:

cl /dbuilding_native_dll /ld native.cpp ...     creating library native.lib , object native.exp 

now i'd use c++/cli application:

managed.cpp:

#include "native.h"  int main() {     native* native = new native();     native->f(); } 

i can build in clr mode "ijw":

cl /clr managed.cpp native.lib ...  /out:managed.exe managed.obj native.lib 

but not in clr mode "pure":

cl /clr:pure managed.cpp native.lib microsoft (r) c/c++ optimizing compiler version 16.00.40219.01 microsoft (r) .net framework version 4.00.30319.18047 copyright (c) microsoft corporation.  rights reserved.  managed.cpp c:\users\...\native.h(9) : warning c42 72: 'native::f' : marked __declspec(dllimport); must specify native calling c onvention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::native' : marked __declspec(dllimport); must specify native cal ling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::~native' : marked __declspec(dllimport); must specify native ca lling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::native' : marked __declspec(dllimport); must specify native cal ling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::operator =' : marked __declspec(dllimport); must specify native  calling convention when importing function. microsoft (r) incremental linker version 10.00.40219.01 copyright (c) microsoft corporation.  rights reserved.  /out:managed.exe /clrimagetype:pure managed.obj native.lib managed.obj : error lnk2028: unresolved token (0a000009) "public: void __clrcall  native::f(void)" (?f@native@@$$fqamxxz) referenced in function "int __clrcall m ain(void)" (?main@@$$hymhxz) managed.obj : error lnk2019: unresolved external symbol "public: void __clrcall native::f(void)" (?f@native@@$$fqamxxz) referenced in function "int __clrcall ma in(void)" (?main@@$$hymhxz) managed.exe : fatal error lnk1120: 2 unresolved externals 

so seems break build lack of native calling convention.

and indeed if specify it:

#ifdef building_native_dll #define dllapi __declspec(dllexport) #else #define dllapi __declspec(dllimport) #endif  class dllapi native {     public: void __thiscall f(); }; 

it's better:

cl /clr:pure managed.cpp native.lib microsoft (r) c/c++ optimizing compiler version 16.00.40219.01 microsoft (r) .net framework version 4.00.30319.18047 copyright (c) microsoft corporation.  rights reserved.  managed.cpp c:\users\...\native.h(10) : warning c4 272: 'native::native' : marked __declspec(dllimport); must specify native cal ling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::~native' : marked __declspec(dllimport); must specify native ca lling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::native' : marked __declspec(dllimport); must specify native cal ling convention when importing function. c:\users\...\native.h(10) : warning c4 272: 'native::operator =' : marked __declspec(dllimport); must specify native  calling convention when importing function. microsoft (r) incremental linker version 10.00.40219.01 copyright (c) microsoft corporation.  rights reserved.  /out:managed.exe /clrimagetype:pure managed.obj native.lib 

but still warnings on generated members.

so here questions:

• is possible specify calling convention whole class, generated members inherit?
• if header file not specify calling convention , if can't modified how build in clr mode "pure"?

thanks.

try bracketing #include of native header file with

#pragma managed(push, off) #include "native.h" #pragma managed(pop) 

obviously /clr:pure compilation unit cannot have unmanaged definitions of functions, these declarations of imports -- should work.

overall, however, exporting entire classes not recommended. safer export factory functions , use class construction, return pointer interface (base class pure virtual members) , use member access. com does, , technique extremely compatible across language , compiler versions.