Do you know any run-time differences between Compact and Full Framework code?

Question

There are a number of run-time differences in compatible code between these two versions of .NET.

Here is a list of differences so far:

• Graphics.DrawRectangle - differs by 1 pixel
• Graphics.DrawString - Loses the line wrap if used with a StringFormat with both StringAlignments set to Center.
• Most file operations - compact framework needs a full path
• The status of a socket after BeginAccept
• (In WinCE 5 at least) you cannot use a socket to send data synchronously with a timeout (without is okay but you risk hangs)
• Bitmaps (all Image-derived classes really) behave differently in how their resources are cleaned up. - ctacke
• The default font for labels and treeviews in the CF was larger - Darwyn
• When a label is disabled in CF it is just grayed out (the full .net framewark outlines the text with another color) - Darwyn
• Assembly paths are returned in a different format on the desktop from System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase - Qwertie

Do we also have any more to add?

Answer 1

Depending on what you are looking for there is a Differences between .NET Compact Framework and .NET Framework article on MSDN.

Answer 2

I've noticed some differences when I had to port a CF app over to the full .net framework.

• The default font for labels and treeviews in the CF was larger

• When a label is disabled in CF it is just grayed out (the full .net framewark outlines the text with another color)

Answer 3

Bitmaps (all Image-derived classes really) behave differently in how their resources are cleaned up.

Answer 4

Assembly paths are returned in a different format on the desktop from

System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase

This returns a normal path under Win CE, but gives a URL (file:///c:/...) on the desktop framework. The property

System.Reflection.Assembly.GetExecutingAssembly().Location

returns a normal path (C:...) in the desktop framework, but is not available at all in the Compact Framework.

Here is a property that returns the folder in which your application is located:

public static string AppFolder
{
 get {
  #if !WindowsCE && !PocketPC
  string exeFile = System.Reflection.Assembly.GetExecutingAssembly().Location;
  #else
  // This returns a normal path under CE, but gives a URL (file:/...) on the desktop
  string exeFile = System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase;
  if (exeFile.StartsWith("file:///"))
   exeFile = exeFile.Substring("file:///".Length);
  #endif
  return System.IO.Path.GetDirectoryName(exeFile);
 }
}

Answer 5

From Mitchel Sellers' list, these are some the characteristics that make Compact progreamming ... interesting.

The common language runtime for the .NET Compact Framework is approximately 12 percent the size of the full .NET Framework common language runtime.

The functionality of a current directory is not present in the Windows Embedded CE operating system.

Windows Embedded CE resolves a file name that is specified without path information as being in the root directory of the device, not in the application directory.

The .NET Compact Framework processes Uniform Resource Identifier (URI) strings prefixed by file:// differently from the full .NET Framework.

Because of size and performance considerations, the .NET Compact Framework does not support binary serialization using BinaryFormatter, or SOAP serialization using SoapFormatter.

Not all socket options are supported.

Because device I/O occurs in RAM, file and directory attributes cannot be set or accessed.

---

The Console is only provided at the hardware vendor's option.

Only 12% of the .NET Framework. I cleverly figured out that means that 88% is missing. And you will probably want some of it.

Pretty remarkable that so much is omitted or distorted because it won't fit into several hundred MB; compared to typically less than 10 MB for classical Mobile devices.