Andrew Arnott : Mobile devices

GZip encoder for Compact WCF

andarno — Wed, 01 Oct 2008 05:13:07 GMT

The GZip encoder is not included in NetCF as it is on the desktop WCF, but it isn't hard to build yourself and in fact we have released a sample of exactly how to add your own GZip encoder to NetCF:

http://go.microsoft.com/fwlink/?LinkId=108652

So many people have asked me for it lately I thought I'd better just post the link. Have fun!

Write a NetCF app that provisions your device from your device

andarno — Mon, 04 Feb 2008 10:42:31 GMT

My first post in the provisioning series introduced what provisioning of your Windows Mobile device means and the basics of why you would want to do it. In future posts I'll give some concrete examples of XML that accomplish a few common tasks. But what good are XML examples if you can't try them out on your device or emulator? It would be much better if you had an app that would let you write in XML and see what happens when you send it to the provisioning API of Windows Mobile. I'd like to introduce you to a sample I wrote just for this purpose.

The open-source Windows Mobile Provisioning tool is a .NET Compact Framework application that exposes provisioning directly to the user. It will take strings of XML and pass them directly to Windows Mobile and return the resulting XML. It also has an interface to help you set a proxy server and add domains to the Work network and crafts the provisioning XML for you.

Over time I may add additional built-in provisioning scenarios to the sample. But for now, download it, compile it, and try it out. Let me know what you think, either here or on the Discussions page for this sample.

XmlSerializer compatibility between NetCF and the desktop

andarno — Thu, 24 Jan 2008 00:28:43 GMT

The XmlSerializer found in the .NET Compact Framework has a very different implementation than the one found in the full .NET Framework. The reasons for the differences include size and performance constraints that make the desktop's XmlSerializer inappropriate for devices.

As a result of the different implementation, there are inevitably going to be differences between how each serializer turns objects into XML and back again. We try to minimize these differences so that your C# code will run on NetCF and desktop in a very portable way. When we find differences, we have to weigh the consequences of possibly breaking backward compatibility with applications written for earlier versions of NetCF against breaking compatibility with desktop for current and future applications.

One area where cross-platform compatibility becomes particularly important is in web services. When you generate web service proxies for your NetCF applications using Visual Studio's Add Web Reference function (or the command line wsdl.exe, xsd.exe, or NetCFSvcUtil.exe tools) you expect those proxies to serialize to XML that the service is expecting. These tools are generally developed and tested against the desktop's version of the XmlSerializer more thoroughly than against the NetCF XmlSerializer. So any differences in how NetCF's XmlSerializer works could cause incompatible xml to be sent to a service.

As I have been code reviewing .NET Compact Framework's version of the serializer and fixing bugs in it, I've come across a number of differences in how the two serializers behave that can affect web services. Some of these fixes made it into NetCF 2.0 SP2. Many more made it into NetCF 3.5. But quite a few issues were discovered too late to fix in the NetCF 3.5 release.

In an upcoming NetCF release there are likely to be some breaking changes to the way the XmlSerializer works in order to improve web service and desktop compatibility. This is likely to only affect applications that use multiple namespaces in a single type that is being serialized as that is where most of the bugs seem to be.

You can prepare for these changes by testing your application on the full .NET Framework today. If it runs correctly there, then it will probably run correctly on a future version of the .NET Compact Framework. If you notice that the XML the desktop produces is different than what NetCF produces, you will probably need to adjust your code so that it produces the desired XML on the full Framework, and consider releasing a service pack for your own application to your customers who are using new versions of NetCF.

A full list of breaking changes is published with each release of the .NET Compact Framework. You should review those if your NetCF app uses the XmlSerializer.

Using the XmlSerializer as an XmlObjectSerializer with WCF

andarno — Fri, 18 Jan 2008 23:06:54 GMT

The Windows Communication Foundation introduced the new DataContractSerializer to replace the XmlSerializer in many scenarios. The DataContractSerializer is faster than the XmlSerializer, but has certain limitations. For example it does not support serializing an object's members as XML attributes. When you write a WCF client that calls a service, WCF will generate a proxy class that defaults to using the DataContractSerializer and falls back to the XmlSerializer if the service uses features that the DataContractSerializer does not support. This fallback mechanism is automatic if you're using WCF's service model.

But if you're working at WCF's messaging layer, you must explicitly choose which serializer to use. You can use any serializer that derives from System.Runtime.Serialization.XmlObjectSerializer. System.Runtime.Serialization.DataContractSerializer already derives from this class -- but System.Xml.Serialization.XmlSerializer does not. So you have some work to do before you can use the XmlSerializer as your serializer of choice at the messaging layer of WCF.

In order to use the XmlSerializer to send messages with WCF, we have to define a class that derives from XmlObjectSerializer and uses the XmlSerializer internally. In essence we will create a wrapper class for the XmlSerializer that makes it look and work like an XmlObjectSerializer. XmlObjectSerializer is an abstract class with only a few methods we need to implement.

Below is a sample of a class that will do just that.

namespace Microsoft.ServiceModel.Samples
{
    using System;
    using System.Diagnostics;
    using System.IO;
    using System.Text;
    using System.Xml;
    using System.Xml.Serialization;
    using System.Runtime.Serialization;

    public class CFMessagingSerializer : XmlObjectSerializer
    {
        readonly Type objectType;
        XmlSerializer serializer;

        public CFMessagingSerializer(Type objectType)
            : this(objectType, null, null)
        {
        }
        
        public CFMessagingSerializer(Type objectType, string wrapperName, string wrapperNamespace)
        {
            if (objectType == null)
                throw new ArgumentNullException("objectType");
            if ((wrapperName == null) != (wrapperNamespace == null))
                throw new ArgumentException("wrapperName and wrapperNamespace must be either both null or both non-null.");
            if (wrapperName == string.Empty)
                throw new ArgumentException("Cannot be the empty string.", "wrapperName");
            
            this.objectType = objectType;
            if (wrapperName != null)
            {
                XmlRootAttribute root = new XmlRootAttribute(wrapperName);
                root.Namespace = wrapperNamespace;
                this.serializer = new XmlSerializer(objectType, root);
            }
            else
                this.serializer = new XmlSerializer(objectType);
        }

        public override bool IsStartObject(XmlDictionaryReader reader)
        {
            throw new NotImplementedException();
        }

        public override object ReadObject(XmlDictionaryReader reader, bool verifyObjectName)
        {
            Debug.Assert(serializer != null);
            if (reader == null) throw new ArgumentNullException("reader");
            if (!verifyObjectName)
                throw new NotSupportedException();

            return serializer.Deserialize(reader);
        }
        
        public override void WriteStartObject(XmlDictionaryWriter writer, object graph)
        {
            throw new NotImplementedException();
        }

        public override void WriteObjectContent(XmlDictionaryWriter writer, object graph)
        {
            if (writer == null) throw new ArgumentNullException("writer");
            if (writer.WriteState != WriteState.Element)
                throw new SerializationException(string.Format("WriteState '{0}' not valid. Caller must write start element before serializing in contentOnly mode.",
                    writer.WriteState));
            using (MemoryStream memoryStream = new MemoryStream())
            {
                using (XmlDictionaryWriter bufferWriter = XmlDictionaryWriter.CreateTextWriter(memoryStream, Encoding.UTF8))
                {
                    serializer.Serialize(bufferWriter, graph);
                    bufferWriter.Flush();
                    memoryStream.Position = 0;
                    using (XmlReader reader = new XmlTextReader(memoryStream))
                    {
                        reader.MoveToContent();
                        writer.WriteAttributes(reader, false);
                        if (reader.Read()) // move off start node (we want to skip it)
                        {
                            while (reader.NodeType != XmlNodeType.EndElement) // also skip end node.
                                writer.WriteNode(reader, false); // this will take us to the start of the next child node, or the end node.
                            reader.ReadEndElement(); // not necessary, but clean
                        }
                    }
                }
            }
        }

        public override void WriteEndObject(XmlDictionaryWriter writer)
        {
            throw new NotImplementedException();
        }
        
        public override void WriteObject(XmlDictionaryWriter writer, object graph)
        {
            Debug.Assert(serializer != null);
            if (writer == null) throw new ArgumentNullException("writer");
            serializer.Serialize(writer, graph);
        }
    }
}

.NET Compact Framework 3.5 Power Toys RTW

andarno — Tue, 11 Dec 2007 01:49:10 GMT

The .NET Compact Framework 3.5 Power Toys have been released. You can download them from here.

Tools included in this package:
Remote Performance Monitor and GC Heap Viewer – Provides real time counter data (ranging from Garbage Collector activity to type loading info) on a running NETCF application. The GC Heap Viewer feature allows you to capture the managed heap at any moment your app is running to view live references, and allows you to compare multiple snapshots to find memory leak issues.
NETCF CLR Profiler – CLR Profiler is an instrumenting allocation profiler for NETCF applications. It provides detailed allocation visualizations, allocation callstacks visualizations and useful for diagnosing memory management issues.
App Configuration Tool (NetCFcfg.exe) - On-device tool for specifying what version of the NETCF runtime an application will run against, displaying installed versions of NETCF and displaying info about DLLs in the GAC.
NETCF ServiceModel Metadata Tool – The .NET Compact Framework ServiceModel Metadata Tool (netcfsvcutil.exe) allows you to generate a Windows Communication Foundation (WCF) client proxy to help developers consume WCF services on device. Like svcutil.exe, which is the desktop version of the utility, netcfsvcutil.exe is a command-line tool that generates service model code from metadata documents and generates metadata documents from service model code.
Remote Logging Configuration Tool – The Logging Configuration Tool enables users to easily configure logging options on a NETCF device including: loader, interop, network, error and finalizer logs.
NETCF Network Log Viewer – A utility for viewing NETCF network log data.

Provisioning smart devices: an introduction

andarno — Thu, 29 Nov 2007 19:19:23 GMT

A lot of questions on the MSDN forums center around how to customize a device or an app to prefer a specific network connection over another. The correct way to accomplish this is by "provisioning" the device. In fact a great many aspects of the device and the applications on it can be configured through 'provisioning' the device.

Since provisioning is so broad, I've just started a tag for this topic, and I expect to post several times to this blog in the next little while on how to accomplish several common tasks through provisioning the device. But because the topic is so broad, I want to give a brief overview of what it is, and point you to several MSDN resources that can help you get started.

You should be warned that provisioning a device incorrectly can wreak havoc with whatever system you altered in the process. This means your cell phone or data plan could quit working, or your data plan will become the preferred network over wi-fi and cost you lots more money, or that all your browser favorites will disappear. In short, lots of bad things can happen so you should consider testing on a device emulator before doing anything on a physical device.

To provision a device, you send an XML document to the device via the device's DMProcessConfigXML native function or remotely from a desktop computer via the ProvisionDevice(...) method on the Microsoft.SmartDevice.Connectivity.Device managed class. The .NET Compact Framework offers no managed wrapper to the DMProcessConfigXML function, so if you want to provision your device from an application running on the device itself you will have to P/Invoke into this function on your own. It turns out that doing this properly is tricky and deserves a post of its own (stay tuned). But if you're eager to get started check out the P/Invoke.Net page on the function that I recently added.

The XML document you send to the device is carefully crafted to either set or query parameters of some characteristic of the device. These characteristics may relate to your browser favorites list, the network connections available, the proxy server(s) available for use, speed dial settings, sounds, ActiveSync, etc. etc. The full list is available from MSDN: Configuration Service Provider Reference for Windows Mobile-Based Devices. For the purposes of NetCF-related efforts however, on this blog I will focus primarily on the network-related configuration settings you can reach through provisioning.

In response to the XML document you send to the device, you get another XML document with the results of your query. If you were just setting parameters, you essentially get the same XML document back. If you were querying for existing settings, you will get an XML document similar to your request, except with all the values you requested filled in.

In a future post I'll walk through a example of creating a NetCF app that allows the user to write XML, send it to the device, and read the XML that comes back. Subsequent posts will then describe various XML snippets that will accomplish some useful tasks. If you want to see me cover a specific scenario and give example XML (since I personally find the MSDN docs for XML samples to be sparse at best) drop a comment below and I'll do the best I can to cover the topics.

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

andarno — Tue, 20 Nov 2007 01:18:04 GMT

A bug was discovered recently in the .NET Compact Framework version 2.0 (SP2 and earlier) and 3.5 that causes HttpWebRequest's directed at some HTTPS servers to fail with this error: (for web services)

System.Net.WebException: Unable to read data from the transport connection. ---> System.Net.Sockets.SocketException: Unknown error (0x0).
   at System.Net.HttpWebRequest.fillBuffer(HttpWebRequest request, Connection connection, CoreResponseData data)
   at System.Net.HttpWebRequest.getLine(HttpWebRequest request, Connection connection, CoreResponseData data)
   at System.Net.HttpWebRequest.parseResponse(HttpWebRequest request, Connection connection, Boolean defaultKeepAlive)
   at System.Net.HttpWebRequest.startReceiving(Connection connection)
   at System.Net.Connection.startReceiving(Object ignored)
   at System.Threading.ThreadPool.WorkItem.doWork(Object o)
   at System.Threading.Timer.ring()

   at System.Net.HttpWebRequest.finishGetResponse()
   at System.Net.HttpWebRequest.GetResponse()
   // ...
   at Program.Main(String[] args)

For standard HttpWebRequest calls from your app the stack trace would be different, although the exception message and cause would be the same.

While there are multiple reasons this exception can be produced, one thing that can cause it is if the server sends an empty encryption packet to the NetCF client. Here is an illustration of the encryption process that occurs on the server for HTTPS:

First, a memory buffer is initialized with unencrypted data that the server wants to send to the client over the network.

Step 1:

unencrypted data

Next, the server makes a call to EncryptMessage and the unencrypted data is encrypted in place. A header and footer is added to the buffer:

Step 2:

header

encrypted data

footer

This header if 5 bytes long, and the footer is several more bytes. This entire packet, which is necessarily longer than the original unencrypted data, is then sent down the wire where the process is reversed using a call to DecryptMessage.

The trouble with NetCF's SSL stack is when the server encrypts a buffer of zero length and sends it to the client:

Step 1:		0 bytes of unencrypted data
Step 2:	header	encrypted representation of a zero-length buffer	footer

Although the original data had a length of zero, the encrypted version of it actually has a non-zero length. When this packet is sent to a NetCF client, current versions of NetCF decrypt the packet and return a zero length buffer to the caller. The semantics of a network Read method is traditionally that it blocks until some data is received, and if a zero length buffer is returned it is the sign that the socket was closed. Because NetCF will return an empty buffer after decrypting an "empty" encryption packet, the caller may misinterpret this as a sign of a disconnected socket and terminate the connection.

In fact this is exactly what happens in NetCF's web services code when calling services over SSL that respond with empty encryption packets. As a result the connection fails before the response is fully received and an exception is thrown.

What causes the server to send these empty encryption packets? Technically it's legally allowed for these empty packets to be sent (although they are pointless), so depending on your server and its configuration this may never happen or it may happen regularly.

Unfortunately there is no way to get NetCF to ignore these packets, so the only workarounds are these, in order of simplicity:

Don't use SSL to make your request (security implications here of course by sending your request and its response in clear text)
Reconfigure your existing server in some way to get it to avoid generating these empty encryption packets.
Build a new web server that will forward your device's requests on a separate connection to the ultimate target server and forward the responses back to the device. This would work for web sites and web services. But this new front-end server (which serves something of the role of a proxy server) would have to be configured to not generate these empty encryption packets.
[Added 1/2/08] Build a device-side web proxy that calls into the SSPI functions itself (native would probably be easier than managed for this). Then have your managed app call into the proxy. This proxy would be responsible for consuming the empty packets and re-encrypting everything (if necessary to secure IPC) for the app on the same device without any empty SSL packets.
Wait until a future version of NetCF that fixes this bug.
Write your own HTTPS client using native code or P/Invoke'ing from NetCF (difficult to get right).

So how do you know for sure if the HTTPS server is sending empty encryption packets that are causing your NetCF clients to fail? I wrote a native C++ app that calls a web server on an HTTPS connection and detects these packets. (No, I'm afraid it can't filter them out for NetCF clients) By running this app against your web server the app will tell you whether your server generates these empty packets. At least then you know what's going on.

[Updated Feb 1, 2008] You can download the source code from its resource page on the MSDN Code Gallery.

Trying out the iPhone

andarno — Wed, 07 Nov 2007 11:00:21 GMT

So I had the opportunity to try out the iPhone for a day. Overall I was impressed, but there were some very basic features missing from many of the otherwise killer apps that I would greatly miss if I was to use the iPhone as my primary PDA and phone. Here is a brief summary:

	Pros	Cons
Browsing	Beautiful.	No copy and paste, so no convenient way to copy that phone number from a web page into the dialer. No support for flash or any other 3rd party extensions. No way to change the Google search default (that I could see). Slow over Edge -- though much better over Wi-Fi. I found I like to browse faster than the rendering engine can keep up, resulting in waiting while the page that has already downloaded just draws to the screen.
Notes	Convenient, good auto-correct feature does a lot to make up for the non-tactile interface	No undo. And no select feature either. If you want to delete more than a few characters, you'll hold down the delete key, end up deleting too much accidentally, and look for that missing Undo key, only to give up and accept data loss.
Email	Nice to have a built-in app, especially when it connects to Gmail. Good to have IMAP support to make up for the poor "Gmail"-dedicated option.	When I added Gmail, all emails came in as Unread. No bulk method to mark them as read either, so I would have had to open each of 47 messages to mark them as read. Also no conversation view of email as Gmail on the web has -- just the archaic individual message listing.
Overall Stability	The system was responsive most of the time.	Sometimes the whole screen would just freeze for several seconds for no apparent reason. It would not respond to the one button I could press or any touch on the screen.
Google Maps	Multi-touch makes this great.	I actually have found Microsoft Live Maps to provide a more accurate freeway traffic condition (don't know why), so I would prefer to have Live Maps offered.
Voicemail	Of course I'm happy to see an app to visually make reviewing voicemails as easy as sifting an Inbox.	No cons here -- except that I rarely have more than a single voicemail message waiting for me anyway, so I wouldn't call this a killer app.
YouTube	Entertaining	Poor video quality -- worse than a desktop computer it seemed. Slow downloads over the Edge data connection.
Weather	Convenient one or two touch access to weather daily forecasts.	Unlike the dynamic calendar button on the home screen, the weather button reports a static "sunny 73 degree" all day every day.
Camera	High quality. Cute animated shutter.	Issues pressing the "take picture" button not always taking the picture. It could cause you to miss the perfect moment for your picture.
Phone dialer	Nice interface.	I actually prefer the Windows Mobile Smartphone interface because it is more friendly to one-handed use.
Keyboard	I personally really like the touchscreen keyboard, especially because it affords more room for the beautiful display. Auto-correct makes up where mistakes occur.	Virtually impossible to use with just one hand. And yes, more mistakes are made than with a slide-out qwerty keyboard.

Then of course there's the closed platform problem, and I miss the voice-activated search I have on my Windows Mobile Smartphone.

Bottom line

Microsoft employment aside (since I tend to not let that get in the way of my personal purchase decisions), would I get an iPhone if I had $500 and a two-year contract I cared to get into? I'm not sure. If I did it would be for the mobile browsing experience and nothing more. That's not worth $500 plus a two-year contract. Check out a recent post I did on Windows Mobile Smartphones for how I like to find inexpensive, very usable smartphones.

Workaround for XmlSerializer T[] and List bug

andarno — Tue, 06 Nov 2007 00:34:27 GMT

The XmlSerializer in NetCF 2.0 has a bug where if a single serialization requires reflecting into types that use a mixture of Collection<T>-like types for the same T the XmlSerializer will throw an exception. Here an example where CF 2.0 would crash:

public class SerializingType1 {
   public string[] FirstNames;
   public List<string> PhoneNumbers;
}

This type would fail to serialize under NetCF 2.0 because T = string would appear in two kinds of collections. This next example would also fail if you were serializing TypeA, because it contains a TypeB instance which has the another kind of T collection.

public class TypeA {
   public string[] FirstNames;
   public TypeB b;
}
public class TypeB {
   public List<string> PhoneNumbers;
}

If you can change the public API to use all T[] or List<T> and avoid the mixture, you've worked around the problem. So this would be the simplest workaround:

public class SerializingType1 {
   public List<string> FirstNames;
   public List<string> PhoneNumbers;
}

If you can't change the public API to maintain compatibility for your customers, here's another workaround that will eliminate the mixture for the XmlSerializer but keep the mixture for your customers.

public class SerializingType1 {
   [XmlIgnore]
   public string[] FirstNames {
      get { return firstNamesHiddenList != null ? firstNamesHiddenList.ToArray() : null; }
      set { firstNamesHiddenList = value != null ? new List<string>(value) : null; }
   }
   [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
   [XmlArray("FirstNames")]
   [Obsolete("This member is for internal use only.")]
   public List<string> firstNamesHiddenList;
   public List<string> PhoneNumbers;
}

This will make the XmlSerializer work, and the API to the customer appear to be the same, except for a public member that they should never use directly that is only there (and public) because the XmlSerializer requires it. EditorBrowsableAttribute and ObsoleteAttribute are there to help the customer to not run into that member and use it when you didn’t intend them to.

This bug is fixed in .NET Compact Framework 3.5.

What do you think of the new WCF 'Store and forward' Mail Transport?

andarno — Mon, 29 Oct 2007 22:53:53 GMT

With the .NET Compact Framework 3.5 release which comes with Visual Studio 2008, a new Windows Communication Foundation transport is introduced that uses email as the communication mechanism.

Others have already blogged about this new transport including Roman Batoukov and David Kline.

I'd like to take a poll of the audience to see how you like the transport, including the documentation and samples that we ship with it. Can you think of uses for an email transport? Do you have any trouble figuring out how to use it? Will you use it exclusively on desktop machines, mobile devices or both?

Please comment below and let me know what you're doing with it! We'd like to know about any pain points you run into so we can fix it in the next version.

Why wait for a Zune Phone? Smartphones are here now!

andarno — Mon, 29 Oct 2007 18:06:50 GMT

The iPhone was a hit, and people look to Microsoft to produce a ZunePhone in some future version of their Zune music player. But I ask you, "Why?!" What you may not be aware of is that Windows Smartphones already do everything that we hope ZunePhone will do. Just check out this feature list:

Music player (WMA, MP3, WAV, ringtones), with all the convenient music navigation of browsing by artist, album, genre, track, etc.
Video player (WMV, and I don't know what other formats)
DRM-free
Bluetooth and wi-fi support (depends on actual phone)
Phone
Contact list (that syncs with Outlook/Exchange)
Calendar (that syncs with Outlook/Exchange)
Email (that syncs with Outlook/Exchange)
Voice notes
Games
3rd-party apps (step aside iPhone!)
Not locked as a platform to any particular carrier
Free downloads of ringtones and apps (no carrier-tax just to put apps on your phone)

I have only listed features that might appear on some future ZunePhone (I have no insider information to make announcements for future Zunes, so don't read into these). There are way more features on Smartphones than just what I have listed here.

Just a small plug for the contacts list in a Smartphone: I've never seen and could never imagine a more easily and quickly navigable interface than the contacts list on a Windows Mobile Smartphone. I can usually go from pulling out my phone to dialing someone's number in about three key presses.

The price for one of these amazing Smartphones? Since we don't have a closed platform like Apple, I can't give you a single price because there are so many different devices that you can choose from. But here are a few really neat models available today with their links:

Personally, I bought an HTC 2125 Smartphone off of eBay for $100. I thought it had the perfect balance of fits-in-your-pocket and decent viewable screen size. As I've demonstrated, it runs circles around the iPhone and what I expect from the not-yet-produced ZunePhone, and it's at a small fraction of the cost, and with no two-year contract either.

Compare that to iPhone's $500 price tag plus 2 year contract requirement. Oh, and it only works with AT&T (officially anyway).

So get out there and buy a Windows Mobile Smartphone today!

Calling WCF services from NetCF 3.5 using Compact WCF and NetCFSvcUtil.exe

andarno — Thu, 13 Sep 2007 02:29:00 GMT

The .NET Compact Framework 3.5 adds a subset of the Windows Communication Foundation (WCF or "Indigo") to smart devices, allowing them to communicate with desktop WCF components with all the flexibility of multiple, interchangeable service bindings and endpoints. Although it ships out of the box only with support for message-level communication (no service calls, per se), we have a code generation tool that will allow you to call WCF or other WSDL-publishing services.

Desktop has an svcutil.exe tool that generates client proxy code, but the source code it generates cannot compile against NetCF libraries because NetCF does not include all the classes referenced from that source code. While you can modify the code by hand to eventually get it to work with NetCF, we offer an easier way.

The NetCFSvcUtil.exe tool that ships as part of the Power Toys for .NET Compact Framework 3.5 supports many of the same command-line switches that svcutil.exe does, but performs a few additional/modified steps:

Verifies that the service being consumed offers endpoints compatible with the feature subset included in NetCF 3.5.
Generates the client proxy class in C# or VB that compiles against NetCF or desktop WCF.
Generates code for a CFClientBase class that fills in where NetCF doesn't support calling WCF services.
Does not generate a .config file to store the endpoint information. This information is stored in the client proxy code. If an X509 certificate required by the endpoint, that must be passed into the proxy class' constructor by your code.

Assuming that you have a service running at http://localhost/service/service.svc on your desktop computer and a device application in your C:\deviceapp directory, you could generate the code to call the service from NetCF using the following command line. Be sure NetCFSvcUtil.exe is in your path. Also be sure to use a machine name that can be reached from your device. If you use "http://localhost/..." as your argument to the tool, your device will look for localhost (which is the device itself!) and not find the service that is running on your Windows box.

C:\deviceapp>netcfsvcutil.exe http://<machinename>/service/service.svc

The tool will generate and list two source files. The source file named after your service will be the one that contains the proxy class you'll use from your app. You can use it just like you would the svcutil.exe-generated code, except for the provision of secure endpoints made in my numbered list above.

To use these source files in your application, add them to your Visual Studio project and be sure you have System.ServiceModel.dll and System.Runtime.Serialization.dll in your project's Referenced Assemblies list in Solution Explorer. Calling your service from your device application can be as simple as a couple of lines of code:

CalculatorServiceClient client = new CalculatorServiceClient();
MessageBox.Show(client.Add(3, 5));

Some features that WSDLs and the desktop .NET WCF supports are not supported by the .NET Compact Framework 3.5. Although NetCFSvcUtil.exe generates code to enable some of these features, here is a list of features that remain unavailable for our first version of Compact WCF when calling a WCF service on desktop:

Fault contracts (they are not automatically deserialized for you, but you get the raw xml that you can parse manually)
Custom message headers (including peer hop counts)
Callback contracts
Sessions
Mandatory transactions

And the only desktop binding NetCF 3.5 supports is basicHttpBinding, with optional WS-Security (X.509 only) and no support for WS-ReliableMessaging. NetCF 3.5 adds the new mail transport as well, but NetCFSvcUtil does not support generating proxies for services exposed only on the mail transport.

It's worthwhile to note that any service or client that supports WSDL contracts should be able to intercommunicate, regardless of underlying implementation. This means that if you have a desktop WCF service that you want to call from NetCF, you may also use the already-existing Add Web Reference in Visual Studio to generate code for your client proxy class (the command line equivalent is wsdl.exe). The resulting proxy class may not have as friendly of a public API for you to use, and it won't use the WCF stack, but it is a valid alternative that will work in many cases.

The reverse is also true: you can use WCF to call into old-style .asmx web services. It is not necessary to even know which web service implementation is used on a server. So long as it publishes a WSDL, you're in luck. If it doesn't publish a WSDL, you may still be able to generate a client proxy for it as long as it uses WCF service model and you have access to the managed service assemblies. But that's another topic.

Power Toys for .NET Compact Framework 3.5 CTP released

andarno — Thu, 13 Sep 2007 02:17:00 GMT

The .NET Compact Framework team just released the Consumer Technology Preview (CTP) of the Power Toys for .NET Compact Framework 3.5. These Power Toys are tools to help you build, debug and optimizie your NetCF 3.5 applications.

My personal favorite is the NetCF ServiceModel Metadata Tool (NetCFSvcUtil.exe) which allows NetCF clients to call web services using the Compact WCF stack.

Download it and check it out!

Reflections on having multiple versions of NetCF on your device

andarno — Tue, 28 Aug 2007 01:57:00 GMT

The .NET Compact Framework has had several releases: V1 + 3 service packs, V2 + 2 service packs, V3.5 (to date just betas). Which of these are installed on your device? Can you have multiple versions installed simultaneously? Which version will run your NetCF app if multiple versions are installed? This post addresses all these questions.

Can you have multiple versions installed simultaneously?

NetCF supports side-by-side installations for distinct versions only. For example, V1 and V2 may be installed on your device at the same time, but V2 and V2 SP1 may not be installed at the same time. After V3.5 is released, if a V3.6 were to come out it could be side-by-side installed with V3.5 since it is a distinct version.

If you have a version installed in ROM and a service pack version with the same major and minor numbers installed in RAM, only the version in RAM is actually installed and will run your application.

Discovering which version(s) of NetCF is installed on your device

To see what is installed on your device right now, you can click Start -> Settings -> System -> Remove Programs and see what's listed.

To find which version(s) are installed programmatically (say for a setup program you're writing), you can check the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework. There are DWORD values under it named "X.Y.BBBB.mm" for each installed version of NetCF. A value of 0 means it is installed in RAM while a value of 1 means it is installed in ROM. Beware that if a version is in ROM (i.e. V1) and a newer build of the same version is installed in RAM (i.e. V1 SP3) then both of these will be listed as values in this registry key, although only the SP3 version will actually be present on the system.

[Added 11/29/2007] Check out Neil Cowburn's blog post that contains a table of version numbers and releases for NetCF.

Which NetCF version will run your app?

Review the flow chart or read the discussion below.

A device.config file in your \windows directory may force all applications to run against a particular version of NetCF on your device, although an app-specific .config file takes precedence. In the absence of a device.config file (which is not present by default), the following rules apply.

If only one version of NetCF is installed on your device, it will run your app if it is at least as recent as the NetCF version that the application was built against. So a V2 app will run on NetCF V2 and V3.5, but not on NetCF V1.

Service packs are excluded from this check, so if an application is written against NetCF 2.0 SP2, NetCF 2.0 RTM and SP1 will also run the app. If that app takes dependencies on SP2 bug fixes, the app may break when run on V2 RTM and should therefore check at startup time to see what version of NetCF is running it and warn the user if the appropriate service pack is not installed. The System.Environment.Version property will allow you to check the NetCF version and service pack your app is running on.

If you have multiple versions of NetCF installed, a NetCF app will run against the version of NetCF it was compiled against if it is installed on the device. If that version of NetCF is not installed, then the newest version of NetCF that is installed will be used. For example, a V1 app run on a device with only V2 and V3.5 installed will run on V3.5.

You can alter the default behavior with a .config file to force your app to load with a specific version of NetCF. For example, on a device with V2 and V3.5 installed, you can force the V1 app to run against V2 (rather than the newest V3.5) by using a .config file. For details on this process, see the MSDN documentation How to: Configure Runtime Version.

Should you have multiple versions installed?

That depends on the applications you run and their requirements. In theory, V2 SP2 should be able to run V1 apps because it has a "compatibility mode" that preserves old V1 behavior where needed by older apps. V3.5 will offer the same backward compatibility feature. But this "version coercion" feature is not perfect, and you may find that an app that runs on V1 won't run on V2. In this case, installing V1 side-by-side with V2 is a good idea if you have memory on your device for it.

The WCF subset supported by NetCF

andarno — Tue, 21 Aug 2007 02:23:00 GMT

[Updated: 21Nov07 to clarify that custom headers are supported, but not in NetCFSvcUtil proxy generation]
[Updated: 27Aug07 to correct Gzip sample, and clarify on transports & extensibility]
[Updated: 23Aug07 to add SecurityAlgorithmSuite enumerable]

Many people have been asking about what subset of .NET 3.0's Windows Communication Foundation (WCF) will be supported by the .NET Compact Framework 3.5. Well, here is a table I put together with the answer to that question:

Feature	Desktop WCF	Compact WCF
Bindings:
· BasicHttpBinding	Yes	Yes
· CustomBinding	Yes	Yes
· WindowsMobileMailBinding	N/A	Yes
· ExchangeWebServiceMailBinding	Yes, via NetCF install	Yes
Formatters:
· SoapFormatter	Yes	Yes
· BinaryFormatter	Yes	No
Encoders:
· TextMessageEncoder	Yes	Yes
· BinaryMessageEncodingBindingElement	Yes	No
· MTOMEncoder	Yes	No
· GzipEncoder	Sample available	Sample available
Transports:
· HttpTransportBindingElement	Yes	Yes
· HttpsTransportBindingElement	Yes	Yes
· MailTransportBindingElement	Yes, via NetCF install	Yes
· MsmqTransportBindingElement	Yes	No
· TcpTransportBindingElement	Yes	No
· (other transports)	Yes	No
XmlDictionaryReader/Writer	Yes	Yes; stub around XmlTextReader/Writer
DataContractSerializer	Yes	No; but can be wire-compatible with DCS via XmlSerializer
Service proxy generation	Yes; via SvcUtil.exe	Yes; via NetCFSvcUtil.exe, not integrated into VS2008
· Non-HTTP transports in generated proxies	Yes	Not built-in
· Custom headers in generated proxies	Yes	Not built-in
WS-Addressing	Yes	Yes
WS-Security message level security
· X.509	Yes	Yes
· Username/password	Yes	No
· SecurityAlgorithmSuite.Basic256Rsa15	Yes	Yes
· SecurityAlgorithmSuite.Basic256	Yes	No
WS-ReliableMessaging	Yes	No
Patterns
· Service model	Yes	No
· Message layer programming	Yes	Yes
· Buffered messages	Yes	Yes
· Streaming messages	Yes	No
· Endpoint descriptions in .config files	Yes	No
Channel extensibility	Yes	Yes
Security channel extensibility	Yes	No