Calling a managed (C#) DLL from unmanaged (C++) code in Windows CE

Hi folks,

I know that what I want to achieve works in the "big" framework but I
also read (on the blog of the developer group of the compact framework
itself !) that it should work on Windows CE devices, too. The only
problem: up to now I found no explanation or example, *how* it can be
achieved to call a managed DLL (CF 2.0) from an unmanaged EXE (eVC 4)
on a Windows CE device (Mobile 2003 or Windows CE 5.0).

I've already gone most of the way by following some examples for the
"big" framework - the only (?) problem left is the registration of the
managed DLL on the device so that the EXE cannot find the DLL and its
exported methods.

Any idea how to register the DLL on the device or how else the DLL
could be loaded?

Any help or links to tutorials, posts or examples are welcome!
TIA,
Roland

No, you can't do that in .NET CF. It would require what is commonly caused
"hosting", which is not possible at this version of the run-time.

Paul T.

<ce_clown@gmx.net> wrote in message
news:daaf7136-c77a-43e0-ae75-9557de042074@m44g2000hsc.googlegroups.com...
> Hi folks,
>
> I know that what I want to achieve works in the "big" framework but I
> also read (on the blog of the developer group of the compact framework
> itself !) that it should work on Windows CE devices, too. The only
> problem: up to now I found no explanation or example, *how* it can be
> achieved to call a managed DLL (CF 2.0) from an unmanaged EXE (eVC 4)
> on a Windows CE device (Mobile 2003 or Windows CE 5.0).
>
> I've already gone most of the way by following some examples for the
> "big" framework - the only (?) problem left is the registration of the
> managed DLL on the device so that the EXE cannot find the DLL and its
> exported methods.
>
> Any idea how to register the DLL on the device or how else the DLL
> could be loaded?
>
> Any help or links to tutorials, posts or examples are welcome!
> TIA,
> Roland

As close as you can get is...

http://blogs.msdn.com/mikehall/arch.../26/360936.aspx

-Drew

<ce_clown@gmx.net> wrote in message
news:daaf7136-c77a-43e0-ae75-9557de042074@m44g2000hsc.googlegroups.com...
> Hi folks,
>
> I know that what I want to achieve works in the "big" framework but I
> also read (on the blog of the developer group of the compact framework
> itself !) that it should work on Windows CE devices, too. The only
> problem: up to now I found no explanation or example, *how* it can be
> achieved to call a managed DLL (CF 2.0) from an unmanaged EXE (eVC 4)
> on a Windows CE device (Mobile 2003 or Windows CE 5.0).
>
> I've already gone most of the way by following some examples for the
> "big" framework - the only (?) problem left is the registration of the
> managed DLL on the device so that the EXE cannot find the DLL and its
> exported methods.
>
> Any idea how to register the DLL on the device or how else the DLL
> could be loaded?
>
> Any help or links to tutorials, posts or examples are welcome!
> TIA,
> Roland

Hi Paul,

thank you for your answer.

Well, this is what I read before. But what does it mean when the CF
developer team writes the following (http://blogs.msdn.com/netcfteam/
archive/2005/07/24/442612.aspx):

<quote>
"(...)
The .Net Compact Framework supports interoperating with native COM
objects from managed code as well as allowing native code to interact
with managed objects using COM.
(...)
Com Callable Wrappers (CCWs) - these are used to allow native code to
call managed functions exposed through COM interfaces.

* CCWs are created when an object is marshaled down to native code
as an interface. Once in native code, other interfaces can be
retrieved using QueryInterface, including a number of runtime
implemented interfaces such as IConnectionPointContainer. You can call
managed functions directly through the VTable, or through IDispatch-
>Invoke depending on the type of COM interface as declared in managed
code. The native code must abide by normal reference counting and COM
rules when interacting with CCWs."
</quote>

This sounds to me like if it was possible to do what I intend to.
Maybe you can shed a light on where I am misunderstanding this
statement. I thought I would only have to understand what it means to
"marshal down" an object to native code (which I currently don't) in
order to get it working.

Regards
Roland


On 17 Apr., 17:08, "Paul G. Tobey [eMVP]" <p space tobey no spam AT no
instrument no spam DOT com> wrote:
> No, you can't do that in .NET CF. It would require what is commonly caused
> "hosting", which is not possible at this version of the run-time.
>
> Paul T.
>
> <ce_cl...@gmx.net> wrote in message
>
> news:daaf7136-c77a-43e0-ae75-9557de042074@m44g2000hsc.googlegroups.com...
>
> > Hi folks,
>
> > I know that what I want to achieve works in the "big" framework but I
> > also read (on the blog of the developer group of the compact framework
> > itself !) that it should work on Windows CE devices, too. The only
> > problem: up to now I found no explanation or example, *how* it can be
> > achieved to call a managed DLL (CF 2.0) from an unmanaged EXE (eVC 4)
> > on a Windows CE device (Mobile 2003 or Windows CE 5.0).
>
> > I've already gone most of the way by following some examples for the
> > "big" framework - the only (?) problem left is the registration of the
> > managed DLL on the device so that the EXE cannot find the DLL and its
> > exported methods.
>
> > Any idea how to register the DLL on the device or how else the DLL
> > could be loaded?
>
> > Any help or links to tutorials, posts or examples are welcome!
> > TIA,
> > Roland

Hi,

ce_clown@gmx.net wrote:
> This sounds to me like if it was possible to do what I intend to.
> Maybe you can shed a light on where I am misunderstanding this
> statement.

It comes down to limitations in implementation and hidden assumptions
when people write blog entries.

COM Interop is possible, i.e. classes in the .NET CF environment can be
exposed to the COM environment and visa versa. However there is an
important limitation, the .NET CF environment must create the class and
then pass it to the COM layer. You can't have the COM (or other native)
code attempt to create a class and then automatically have a CLR virtual
machine and related infrastructure started up to host the class (this is
the so called lack of hosting capability).

By Re-arranging some of the sentences slightly within the blog post you
referenced earlier you can come up with the following which may help
explain it better:

"What this means is that a managed application can pass managed
interfaces to native code, and the native code can treat these
interfaces as COM Interface Pointers to make calls back into the managed
code.

However, there is no support for a purely native app to call into
managed code. All pointers need to be passed from managed code to
native code before any calls can be made back into managed code. There
is no registration or activation support in CF 2.0.".

You could possibly achieve what you wanted via another technique, but it
would involve having two processes (your native one, and a .NET CF one)
with some kind of inter process communication channel between them such
as a point to point message queue. If this is worth while or not will
depend upon the nature and amount of managed code you require within
your native application.

What are your reasons behind wanting managed code executed within a
native application?

Hope this helps,
Christopher Fairbairn

> What are your reasons behind wanting managed code executed within a
> native application?

*That* is an easy one - I can give a list of reasons we need hosting without
knowing his situation:

- Managed Today Screen plug-ins
- Managed Control Panel Applets
- Managed Services
- Managed ActiveX controls (for browser plug-ins, etc)
- Enabling managed code-re-use in native projects

There are moreesoteric possibilities too, but those are some fundamentals
reasons we need it.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Hi Chris,

Chris Tacke, eMVP wrote:
> *That* is an easy one - I can give a list of reasons we need hosting without
> knowing his situation:

Yes, I guess the reason why I asked this question was in order to be
able to suggest a possible work around for his particular situation
given the current capabilities of the .NET CF runtime.

Some of the scenarios you mention can be worked around with a little
creative thinking and potential re-architecture of the solution (and/or
accepting some limitations). While other hosting scenarios don't really
have a feasible solution at this point in time.

As an example if he wanted a managed control panel applet, he could
place his System.Windows.Forms based executable within the
\Windows\Start Menu\Settings directory and accept the limited
functionality this provides (see my blog
http://www.christec.co.nz/blog/archives/211 for details).

I for one would love to see hosting supported within future versions of
the .NET CF. It would help bridge the gap between what is possible in
native code and managed code with regards to extension of the OS.

Hope this helps,
Christopher Fairbairn

Hi Christopher,

sorry, I was off this topic for a couple of days for another urgent
project.

First thank you for your explanation - now I understand what works and
what does not - and why.

To answer your question: we already have a managed program with the
functionality of up- and downloading files to a server and calling web
service methods.
As we now need nearly the same functionality for an unmanaged program
we wanted to use the existing functionality instead of rewriting all
that in the unmanaged code. As much more as none of us has ever
consumed a web service from unmanaged code up to now and I would not
know how to do that, given the situation that in C# you only have to
add a web reference to your project whereas it seems that in eVC I
would have to generate all the proxy classes and SOAP stuff myself -
or am I missing something there? Up to now I could not find an example
in C++ to get me starting there. And it would take a lot of time I do
not have to start from scratch.

Thanks a lot!
Regards
Roland

P.S.: does someone happen to know how I can get the Google Groups to
display my nickname instead of my email address as sender (I have to
write directly via Google Groups instead of some newsserver)? I think
I read all help topics in the meantime but I don't find the clue.


On 19 Apr., 05:36, Christopher Fairbairn <christop...@christec.co.nz>
wrote:
> Hi Chris,
>
> Chris Tacke, eMVP wrote:
> > *That* is an easy one - I can give a list of reasons we need hosting without
> > knowing his situation:
>
> Yes, I guess the reason why I asked this question was in order to be
> able to suggest a possible work around for his particular situation
> given the current capabilities of the .NET CF runtime.
>
> Some of the scenarios you mention can be worked around with a little
> creative thinking and potential re-architecture of the solution (and/or
> accepting some limitations). While other hosting scenarios don't really
> have a feasible solution at this point in time.
>
> As an example if he wanted a managed control panel applet, he could
> place his System.Windows.Forms based executable within the
> \Windows\Start Menu\Settings directory and accept the limited
> functionality this provides (see my bloghttp://www.christec.co.nz/blog/archives/211for details).
>
> I for one would love to see hosting supported within future versions of
> the .NET CF. It would help bridge the gap between what is possible in
> native code and managed code with regards to extension of the OS.
>
> Hope this helps,
> Christopher Fairbairn

Hi Drew,

thank you, your link was as enlightening as disappointing - at least
for the "calling a managed dll" part! But now I understand much better
how these COM things work in CE. And I know that there are some
alternative ways to get working what I need.

Regards
Roland


On 18 Apr., 08:10, "DrewCE" <moc.sgodniahc@werd - backwards> wrote:
> As close as you can get is...
>
> http://blogs.msdn.com/mikehall/arch.../26/360936.aspx
>
> -Drew
>
> <ce_cl...@gmx.net> wrote in message
>
> news:daaf7136-c77a-43e0-ae75-9557de042074@m44g2000hsc.googlegroups.com...
>