exporting a C++ object from an evc4 dll to .NET managed C++

  • Thread starter Thread starter christian
  • Start date Start date
C

christian

Hi

When I call a virtual member function on an object which is exported
from an evc4 dll from a .NET managed c++ dll I get an
InvalidProgramException.
It does work when I compile and run on WinXP.
Calling a global function works.

// MyTest.h

#define MYCALL __cdecl

class MyTest
{
public:
MyTest(){}
~MyTest(){}
virtual void MYCALL Test() = 0;
};

// MyTest.cpp

class MyTestImpl : public MyTest
{
virtual void MYCALL Test()
{
::MessageBox(::GetDesktopWindow(),
_T("MyTest"), _T("Pinvoke Test"), MB_OK|MB_ICONASTERISK);
}
};

extern "C"
{
MyTest* MYCALL CreateMyTest()
{
return new MyTestImpl();
}
}

// mytest.def

EXPORTS
CreateMyTest @1


Any ideas?
 
Can you clarify the question a bit more? On what platform? eVC is for CE,
but the Compact Framework, also for CE, doesn't support managed C++. You
can't use an eVC DLL on the desktop.
 
Can you clarify the question a bit more? On what platform? eVC is for CE,
but the Compact Framework, also for CE, doesn't support managed C++. You
can't use an eVC DLL on the desktop.
Click to expand...
1. embedded PC scenario

platform: embedded PC with Windows CE 4.2 - CE PC platform

- a WCE DLL project with the one exported function "CreateMyTest"

- a DLL in MS VC++ .NET compiled with the /clr compiler flag, including
the header MyTest.h and importing the function "CreateMyTest" like this:

// MyTestManaged.cpp
#include "MyTest.h"

[DllImport("CreateMyTest")]
extern "C" MyTest* MYCALL CreateMyTest();
....
public __gc class Tester
{
public:
void TestIt()
{
MyTest* mt = CreateMyTest();
mt->Test();
}
};

- a C# smart device application with a window and a button to run the test

This scenario produces the InvalidProgramException when mt->Test() is
called.



2. Win32 scenario

When I create an (unmanaged) C++ DLL with MS Visual Studio 6 with the
exported function, use the same managed C++.Net DLL which imports the
function and a C# windows application with a window and a button to run
the test it works.
 
Sure. This piece here:
- a DLL in MS VC++ .NET compiled with the /clr compiler flag, including
the header MyTest.h and importing the function "CreateMyTest" like this:
Click to expand...

Generates a binary that is not retargetable to the CF, so it shouldn't work.
There's no way to make it work in this scenario. The CF can call native
DLLs or manged class libraries compiled against the CF, which means they
must be written in VB or C#.
 
Sure. This piece here:




Generates a binary that is not retargetable to the CF, so it shouldn't work.
There's no way to make it work in this scenario. The CF can call native
DLLs or manged class libraries compiled against the CF, which means they
must be written in VB or C#.
Click to expand...
You mean I may not create a managed C++ DLL (which contains only managed
types) and deploy it to the wince target? From my understanding I can
create a managed C++ component and deploy it to any .NET platform.
I don't even use the CF, I only use the CLR and my own classes.

Calling a global function, exported by the (unmanaged) eVC DLL, from the
managed C++.Net DLL works fine, however calling a native C++ object
through an abstract C++ class doesn't work.
 
You mean I may not create a managed C++ DLL (which contains only managed
types) and deploy it to the wince target?
Click to expand...

Yes, that's exactly what I mean.
From my understanding I can
create a managed C++ component and deploy it to any .NET platform.
Click to expand...

Not correct. You cannot expect an assembly built against the full CLR to
work in the compact CLR. There's a lot missing. CF assemblies *can* be
trageted upward to the full CLR.
I don't even use the CF, I only use the CLR and my own classes.
Click to expand...

Again there's a huge (80 meg or so IIRC) difference between the CF and the
FF.
Calling a global function, exported by the (unmanaged) eVC DLL, from the
managed C++.Net DLL works fine.
Click to expand...

Pure luck that the IL was compatible. Don't count on that working in all
cases.
however calling a native C++ object
through an abstract C++ class doesn't work.
Click to expand...

See above
 
Back
Top