The emulator is often *not* an ARM device, but an x86 device (it's running
on your PC, after all). Since you have a native code DLL, that's the most
likely cause of the problem. You say that you were able to call it from an
eVC program. Where was that program running? If on the real device, you
have to use the same environment to test the managed code, to be sure that
you're doing the right thing.
Missing method exception also might indicate that you have not arranged to
export the function calls from your DLL in an unmangled format. C++ mangled
exported function names to include information about the types of parameters
and return types (this is necessary because, in C++, you can overload a
function name with various versions distinguished by their parameter lists
and return types). Since, typically, you are calling the functions from C#
as though they were plain C functions, no mangling is done to the
references. If the functions are not declared with extern "C" in your C++
DLL, and are not listed in a DEF file for the DLL, that's a problem for you.
Paul T.
> Hi,
>
[quoted text clipped - 13 lines]
>
> Ivonne.
Ivonne Riedel - 16 Jan 2006 17:35 GMT
Hi Paul,
The DLL is certainly unmangled. I checked on this with a tool, among mangled
methods those I use for c# are unmangled (by def file).
In order to change the device setting I used the configuration manager.
There I only found pocket pc 2003 (arm v4), x64, win32, smart phone 2003
(arm v4).
In eVC I have for both the client app and the corresponding dll used pocket
pc 2003 (arm v4).
Do I have to get the device as a package from the web?
Thanks for everything
Ivonne.
> The emulator is often *not* an ARM device, but an x86 device (it's running
> on your PC, after all). Since you have a native code DLL, that's the most
[quoted text clipped - 33 lines]
>>
>> Ivonne.
Paul G. Tobey [eMVP] - 16 Jan 2006 18:48 GMT
I don't quite follow the question, but it sounds like you are targeting the
wrong device to run the DLL in the emulator. For PPC2003, you should target
the Pocket PC 2003 Emulator and the DLL should be compiled for x86/Emulator
(I forget the exact terminology). *That* DLL should then be copied to your
emulator, however you want to do that (it doesn't matter how, just that the
right DLL is there).
Paul T.
> Hi Paul,
>
[quoted text clipped - 47 lines]
>>>
>>> Ivonne.
Ivonne Riedel - 18 Jan 2006 01:33 GMT
I think I figured out what the problem is.
The first dll I call via PInvoke has another dll included.
That seems to be the problem in my eyes.
Does anybody have some experience with this issue?
>I don't quite follow the question, but it sounds like you are targeting the
>wrong device to run the DLL in the emulator. For PPC2003, you should
[quoted text clipped - 56 lines]
>>>>
>>>> Ivonne.
Paul G. Tobey [eMVP] - 18 Jan 2006 16:45 GMT
Well, if the second DLL is implicitly loaded by the first, then, as soon as
the managed code tries to call something in the first DLL, things will fail
because the second DLL can't be found and loaded, and that will prevent the
*first* DLL from being loaded, too.
Paul T.
>I think I figured out what the problem is.
> The first dll I call via PInvoke has another dll included.
[quoted text clipped - 61 lines]
>>>>>
>>>>> Ivonne.
Ivonne Riedel - 20 Jan 2006 14:53 GMT
Thank you for your help Tobey.
It was about the configuration, I used multithreaded debug dll for the
runtime lib which was wrong.
It is up and running.
Ivonne.
> Well, if the second DLL is implicitly loaded by the first, then, as soon
> as the managed code tries to call something in the first DLL, things will
[quoted text clipped - 68 lines]
>>>>>>
>>>>>> Ivonne.