c# smart device dll

Hi,

My intention was to build a c# application for smart devices using VS 2005
that is based on a dll.
I created a dll using eVC that worked well (I could access that dll by an
eVC client app).
Trying to port that to c# did not work.
I used Dllimport and put the dll into the project dir and into the windows
dir on the emulator.
I get a system.mssingmethodexception "can't find dll".
The transportation to the emulator was done manually. The dll was built for
pocket pc 2003 (armv4) and the client app was any cpu.
As I am a newbie, maybe I am missing a basic thing?

Thanks

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
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.

"Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
news:dqg9ue$22e$00$1@news.t-online.com...
> Hi,
>
> My intention was to build a c# application for smart devices using VS 2005
> that is based on a dll.
> I created a dll using eVC that worked well (I could access that dll by an
> eVC client app).
> Trying to port that to c# did not work.
> I used Dllimport and put the dll into the project dir and into the windows
> dir on the emulator.
> I get a system.mssingmethodexception "can't find dll".
> The transportation to the emulator was done manually. The dll was built
> for pocket pc 2003 (armv4) and the client app was any cpu.
> As I am a newbie, maybe I am missing a basic thing?
>
> Thanks
>
> Ivonne.
>

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.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
schrieb im Newsbeitrag news:%23$RzQIrGGHA.532@TK2MSFTNGP15.phx.gbl...
> 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.
>
> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
> news:dqg9ue$22e$00$1@news.t-online.com...
>> Hi,
>>
>> My intention was to build a c# application for smart devices using VS
>> 2005 that is based on a dll.
>> I created a dll using eVC that worked well (I could access that dll by an
>> eVC client app).
>> Trying to port that to c# did not work.
>> I used Dllimport and put the dll into the project dir and into the
>> windows dir on the emulator.
>> I get a system.mssingmethodexception "can't find dll".
>> The transportation to the emulator was done manually. The dll was built
>> for pocket pc 2003 (armv4) and the client app was any cpu.
>> As I am a newbie, maybe I am missing a basic thing?
>>
>> Thanks
>>
>> Ivonne.
>>
>
>

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.

"Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
news:dqglg0$1m8$00$1@news.t-online.com...
> 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.
>
> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> schrieb im Newsbeitrag news:%23$RzQIrGGHA.532@TK2MSFTNGP15.phx.gbl...
>> 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.
>>
>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>> news:dqg9ue$22e$00$1@news.t-online.com...
>>> Hi,
>>>
>>> My intention was to build a c# application for smart devices using VS
>>> 2005 that is based on a dll.
>>> I created a dll using eVC that worked well (I could access that dll by
>>> an eVC client app).
>>> Trying to port that to c# did not work.
>>> I used Dllimport and put the dll into the project dir and into the
>>> windows dir on the emulator.
>>> I get a system.mssingmethodexception "can't find dll".
>>> The transportation to the emulator was done manually. The dll was built
>>> for pocket pc 2003 (armv4) and the client app was any cpu.
>>> As I am a newbie, maybe I am missing a basic thing?
>>>
>>> Thanks
>>>
>>> Ivonne.
>>>
>>
>>
>
>

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?


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
schrieb im Newsbeitrag news:eQ3731sGGHA.3320@TK2MSFTNGP12.phx.gbl...
>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.
>
> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
> news:dqglg0$1m8$00$1@news.t-online.com...
>> 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.
>>
>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>> schrieb im Newsbeitrag news:%23$RzQIrGGHA.532@TK2MSFTNGP15.phx.gbl...
>>> 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.
>>>
>>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>>> news:dqg9ue$22e$00$1@news.t-online.com...
>>>> Hi,
>>>>
>>>> My intention was to build a c# application for smart devices using VS
>>>> 2005 that is based on a dll.
>>>> I created a dll using eVC that worked well (I could access that dll by
>>>> an eVC client app).
>>>> Trying to port that to c# did not work.
>>>> I used Dllimport and put the dll into the project dir and into the
>>>> windows dir on the emulator.
>>>> I get a system.mssingmethodexception "can't find dll".
>>>> The transportation to the emulator was done manually. The dll was built
>>>> for pocket pc 2003 (armv4) and the client app was any cpu.
>>>> As I am a newbie, maybe I am missing a basic thing?
>>>>
>>>> Thanks
>>>>
>>>> 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 fail
because the second DLL can't be found and loaded, and that will prevent the
*first* DLL from being loaded, too.

Paul T.

"Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
news:dqk5ra$q6k$01$1@news.t-online.com...
>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?
>
>
> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> schrieb im Newsbeitrag news:eQ3731sGGHA.3320@TK2MSFTNGP12.phx.gbl...
>>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.
>>
>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>> news:dqglg0$1m8$00$1@news.t-online.com...
>>> 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.
>>>
>>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>>> schrieb im Newsbeitrag news:%23$RzQIrGGHA.532@TK2MSFTNGP15.phx.gbl...
>>>> 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.
>>>>
>>>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>>>> news:dqg9ue$22e$00$1@news.t-online.com...
>>>>> Hi,
>>>>>
>>>>> My intention was to build a c# application for smart devices using VS
>>>>> 2005 that is based on a dll.
>>>>> I created a dll using eVC that worked well (I could access that dll by
>>>>> an eVC client app).
>>>>> Trying to port that to c# did not work.
>>>>> I used Dllimport and put the dll into the project dir and into the
>>>>> windows dir on the emulator.
>>>>> I get a system.mssingmethodexception "can't find dll".
>>>>> The transportation to the emulator was done manually. The dll was
>>>>> built for pocket pc 2003 (armv4) and the client app was any cpu.
>>>>> As I am a newbie, maybe I am missing a basic thing?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Ivonne.
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
schrieb im Newsbeitrag news:%234RoS6EHGHA.1396@TK2MSFTNGP11.phx.gbl...
> 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.
>
> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
> news:dqk5ra$q6k$01$1@news.t-online.com...
>>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?
>>
>>
>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>> schrieb im Newsbeitrag news:eQ3731sGGHA.3320@TK2MSFTNGP12.phx.gbl...
>>>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.
>>>
>>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>>> news:dqglg0$1m8$00$1@news.t-online.com...
>>>> 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.
>>>>
>>>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
>>>> com> schrieb im Newsbeitrag
>>>> news:%23$RzQIrGGHA.532@TK2MSFTNGP15.phx.gbl...
>>>>> 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.
>>>>>
>>>>> "Ivonne Riedel" <ivonneundlars@t-online.de> wrote in message
>>>>> news:dqg9ue$22e$00$1@news.t-online.com...
>>>>>> Hi,
>>>>>>
>>>>>> My intention was to build a c# application for smart devices using VS
>>>>>> 2005 that is based on a dll.
>>>>>> I created a dll using eVC that worked well (I could access that dll
>>>>>> by an eVC client app).
>>>>>> Trying to port that to c# did not work.
>>>>>> I used Dllimport and put the dll into the project dir and into the
>>>>>> windows dir on the emulator.
>>>>>> I get a system.mssingmethodexception "can't find dll".
>>>>>> The transportation to the emulator was done manually. The dll was
>>>>>> built for pocket pc 2003 (armv4) and the client app was any cpu.
>>>>>> As I am a newbie, maybe I am missing a basic thing?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Ivonne.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>