.NET Compact Framework Team : Author: Andrew Arnott

Why .NET Compact Framework fails to call some HTTPS web servers

andarno — Wed, 21 Nov 2007 19:57:41 GMT

On his blog, Andrew discusses an HTTPS bug in NetCF that causes NetCF to throw a WebException when connecting to some servers, and its possible workarounds.

Reflections on having multiple versions of NetCF on your device

andarno — Sat, 08 Sep 2007 03:08:35 GMT

Andrew Arnott discusses which versions of the .NET Compact Framework can be side-by-side installed, and which version will run your NetCF app on his blog.

The WCF subset supported by NetCF

andarno — Sat, 08 Sep 2007 03:05:25 GMT

Andrew Arnott details the features of WCF that are and are not supported by NetCF on his blog.

Why your NetCF apps fail to call some web services

NetCFTeam — Thu, 01 Feb 2007 15:39:00 GMT

Here's the scenario: You are writing an NetCF app and trying to call a web service from that app. You generated the code for the client proxy class using Visual Studio's "Add Web Reference" command. Code is generated, you call into it, and you run your app. The call fails with a cryptic error from the web service saying something about a malformed message. If you try the same thing from a desktop app it works perfectly. Sound familiar? Read on for the reason and solution.

I'll address the common cause of xml element mis-ordering here.

Background

Web services and serializers

Calling web services involves serializing objects and sending the resulting xml to the web service, and deserializing the xml response back into objects. This is usually totally transparent to the developer, who just invokes a method and the magic happens behind the scenes. The serialized objects come from classes that are usually generated for you by Visual Studio or command-line tools like wsdl.exe or svcutil.exe. They are constructed based on the service WSDL in such a way that their serialized format matches what the service is expecting, and such that they can be deserialized from the xml the service will respond with. These classes are called "client proxy classes."

Both the desktop .NET Framework and the .NET Compact Framework use the XmlSerializer class for serializing and deserializing these objects. When using the WCF stack, the desktop framework will use their recently added DataContractSerializer instead of the XmlSerializer. Both of these serializers rely on reflection to query the generated client proxy classes and to generate the required xml.

Reflection

The .NET runtime does not ever care about the order a given type's elements are declared. For example, the class:

class Fruit {
   int seeds;
   string color;
}

Is equivalent to

class Fruit {
   string color;
   int seeds;
}

This makes sense. Unfortunately though, because of this when you use reflection to query the members of a type, the order of those members is not guaranteed to be in declaration order, or even to be consistent as you switch between versions of the .NET Framework. In fact, the order in which reflection returns members did in fact change between versions 1.1 and 2.0 of the framework.

How non-deterministic ordering affects web services

Because the serializers in .NET rely on reflection, they are affected by the non-deterministic ordering of members that reflection provides. The order of elements serialized will change with whatever order reflection provides members in.

The .NET designers anticipated this problem, and provided a way to force a specific ordering of serialized elements. The xml serializer attributes that you can decorate your serializable classes with support an Order attribute that you can use to guarantee some desired ordering of elements. For example, you could force the Fruit class used earlier to put <seeds> before <color> no matter what order reflection provides by changing the class to read like this:

class Fruit {
   [XmlElementAttribute(Order=1)] int seeds;
   [XmlElementAttribute(Order=2)] string color;
}

The attributes will retain the Order property's value regardless of reflection order, and that information can be used within the serializer to keep the order to the way the app developer intended.

The problem: why it "works" on desktop's framework and not on NetCF

Although neither desktop nor NetCF's framework guarantees ordering, it so happens that desktop's serializer preserves the order better than NetCF's. Desktop's serializer isn't perfect either, but it's predictable enough that developers take its order for granted and then wonder why NetCF's serializer doesn't behave the same way.

Unfortunately, the wsdl.exe and Visual Studio IDE developers were among those developers that seem to have forgotten that ordering is not guaranteed unless explicitly defined, and so neither generate the code in the client proxy classes to set the Order properties necessary to guarantee the correct ordering. It seems they assumed that declaration order is the default, since the desktop framework (mostly) works that way.

The wsdl.exe tool does offer an "/order" switch that will set order explicitly, but unfortunately this command line tool generates code that won't compile on NetCF projects because of the limited API exposed by NetCF.

The workaround

So until the code is fixed in Visual Studio and/or wsdl.exe, you have a couple of options to get your NetCF projects to call these web services that require specific order:

Use wsdl.exe /order to generate your client proxy class, and then remove all the code not supported by NetCF until your project compiles.
Use Visual Studio to generate your client proxy class, then run wsdl.exe /order in some other directory, and copy just those lines of source code from the resulting class into your project source file that give the explicit ordering.

The ultimate fix

There are a few fixes I'm personally working on to help alleviate this inconvenience for app developers.

I'm trying to get Visual Studio Orcas to include explicit ordering for all generated proxy client classes.
I have changed NetCF's XmlSerializer to preserve declaration order serialization as closely as possible (still not guaranteed). You'll have to be running on NetCF 2.0 SP2 or later to get this fix.
The svcutil.exe tool (which deprecates wsdl.exe) automatically generates explicit ordering code where required with no extra steps for the app developer.

Summary

The XmlSerializer cannot guarantee element order either on desktop .NET Framework or the .NET Compact Framework unless the developer gives the order explicitly, although in some cases the "default" ordering will behave as you expect and in some cases it won't.

The bottom line: where element order is important, use XmlElementAttribute.Order, XmlArrayAttribute.Order, and the other ordering attributes as necessary.

NetCF 3.5's Finalizer Log

NetCFTeam — Mon, 18 Dec 2006 22:02:00 GMT

The .NET Compact Framework has had several loggers (error, interop, loader, and networking) in previous versions. NetCF 3.5 introduces the finalizer logger, which is useful for performance tuning your app by identifying which objects are not being Dispose()'d before being discarded for the garbage collector. This post discusses this logger, how to enable it, use it, and it's file format....(read more)

Platform detection III: How to detect a touch screen on Windows CE in .NET CF

NetCFTeam — Mon, 02 Oct 2006 20:13:00 GMT

Pocket PC's have touch screens. Smartphones don't. While it is straightforward to determine which of these a Windows Mobile device is, there are Windows CE devices that are neither. Some may offer touch screens while others don't. Since a touch screen is really what you may be after (to determine whether you can expect a user to click somewhere on the screen, for example), the better long-term solution would be to check for the touch screen itself. We can't assume that a future version of Windows Mobile won't change the distinctions that currently exist. Here I will discuss ways you can do your own detection....(read more)

Platform detection II: Is your app running on Smartphone or Pocket PC?

NetCFTeam — Fri, 22 Sep 2006 19:24:33 GMT

While both Smartphones and Pocket PCs are based on Windows Mobile, there are some very important differences for developers who are targeting both platforms. Not the least of which are lack of LinkButtons and other clickable elements on Smartphones (since they have no touch screen). In this post I show how to detect whether your app is running on a Smartphone or a Pocket PC style Windows Mobile device.

It is a simple call to SystemParametersInfo to find whether you are running on a Smartphone or a Pocket PC. You need a few constants defined and the P/Invoke marshaling code to make it work from managed code however.

This post builds on the first post in the Platform Detection series. You'll need to build on the code from that post for this post to compile and run. Like the last post, this code uses partial classes, so you can copy and paste the previous post's code into one file and this code into another (removing the first post's Main method) and your project will compile and run.

using System;
using System.IO;
using System.Windows.Forms;
using Microsoft.Win32;
using System.Runtime.InteropServices;
using System.Text;

namespace PlatformDetection
{
    internal partial class PInvoke
    {
        public static string GetPlatformType()
        {
            StringBuilder platformType = new StringBuilder(50);
            if (SystemParametersInfo4Strings((uint)SystemParametersInfoActions.SPI_GETPLATFORMTYPE,
                (uint)platformType.Capacity, platformType, 0) == 0)
                throw new Exception("Error getting platform type.");
            return platformType.ToString();
        }
    }
    internal partial class PlatformDetection
    {
        public static bool IsSmartphone()
        {
            return PInvoke.GetPlatformType() == "SmartPhone";
        }
        public static bool IsPocketPC()
        {
            return PInvoke.GetPlatformType() == "PocketPC";
        }
    }
    class PlatformProgram
    {
        static void Main(string[] args)
        {
            string platform;
            if (PlatformDetection.IsSmartphone())
                platform = "Smartphone";
            else if (PlatformDetection.IsPocketPC())
                platform = "Pocket PC";
            else
                platform = "Other WinCE";
            MessageBox.Show("Platform: " + platform);
        }
    }

}

This is the second post in a series of three on platform detection. Coming up next: detecting the presence of a touch screen.

Platform detection I: How to detect that your app is running in the emulator

NetCFTeam — Sat, 16 Sep 2006 02:59:00 GMT

When you develop your Windows CE or Windows Mobile application in .NET Compact Framework, you probably do a lot of testing on the Microsoft Device Emulators for Smartphone and Pocket PC. Here I describe how to detect whether your program is running on an emulator or a physical device....(read more)