Why Use .NET CF Instead Of Unmanaged Code

[LogicAl]

We'll be developing a real-time embedded app at my office running
under CE. Since I'm quite used to using desktop .NET, my thinking was
to use .NET CF, with unmanaged DLLs to do the real-time work.

However, I was talking to a coworker who's experienced at using .NET
CF & unmanaged code under CE. He told me that .NET CF requires
several seconds for the first load of each form (on an SH7760
platform).

I'm wondering if this seems right, and, if it is right, whether there
are demonstrated productivity or reliability advantages of .NET CF
over unmanaged code.

 

[Jin Chang]

We'll be developing a real-time embedded app at my office running
under CE. Since I'm quite used to using desktop .NET, my thinking was
to use .NET CF, with unmanaged DLLs to do the real-time work.

However, I was talking to a coworker who's experienced at using .NET
CF & unmanaged code under CE. He told me that .NET CF requires
several seconds for the first load of each form (on an SH7760
platform).

I'm wondering if this seems right, and, if it is right, whether there
are demonstrated productivity or reliability advantages of .NET CF
over unmanaged code.

Your friend is correct about the loading time for .NET CF
applications. Because of the limited memory footprint on these
devices, the CF doesn't allow you to pre-compile the MSIL code as is
an option for the full version of .NET. This means that when loading
the .NET CF application, compilation is required (for the relevant
sections of code required). Generally speaking, after the load time
requirements, the performance itself isn't all that bad, but may not
cut it for any real-time applications. This is also true for the full
version of .NET since the Garbage Collection can kick in to disrupt
the real-time requirements.

- Jin

 

[Guest]

The CF certainly can't be used for real-time code. If you are doing any form
of UI or data access it takes very little to argue that you certainly should
consider C# or VB.NET, as it takes an order of magnitude longer to do that
development in native code.

There are a lot of other considerations, but I'll never do another UI in
native code unless there's a specifically compelling business reason to do
so (and I can't imagine one).


--

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

 

[Guest]

Chris is definitely correct about longer development time, but if you are
planning to distribute your application to external users, then you might
consider native forms. I've found that the size of the Compact Framework
discourages some customers from installing your application on their device.
Windows Mobile 5 does not come with the CF 2 and requires the user to install
it if they wish to run your application. Just my 2 cents.

Regards,
Rick D.
Contractor

 

[Hilton]

....or write the app using CF 1.

Chris is definitely correct about longer development time, but if you are
planning to distribute your application to external users, then you might
consider native forms. I've found that the size of the Compact Framework
discourages some customers from installing your application on their
device.
Windows Mobile 5 does not come with the CF 2 and requires the user to
install
it if they wish to run your application. Just my 2 cents.

Regards,
Rick D.
Contractor

 

[Guest]

It certainly boils down to knowing your customer base. For most of what I
do, I dictate the version and customers are happy to oblige (often I control
what's on the device). In other, broader instances it might make sense to
roll back to CF 1.0. Native for UI development would still take a *lot* of
argument to win me over for any new project.


--

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

 

[Hilton]

Native for UI development would still take a *lot* of argument to win me
over for any new project.

I agree with Chris 100%. I wonder if there has been any (unbiased) research
on the productivity gains of using C# over C/C++ (or perhaps Java over
C/C++). And by 'productivity' I include development and QA time, cost,
increased revenues, maintenance, etc. However, there are numerous reasons
such as multi-OS support, existing code base including build processes,
standards in a company, knowledge/experience/familiarity of engineers, ...

There are some things I don't like about C#, but they are very trivial
compared with the extraodinary increase in productivity gained by using C#.

Hilton