REMINDER: Boston Cabana Night – Wednesday, Oct. 6th

Time for a friendly reminder for all the .NET developers throughout New England…

Cabana Night is scheduled for this coming Wednesday, October 6th, at the Microsoft offices in Waltham, MA.

Cabana Night is an opportunity to get any and all questions answered by a who’s who of New England .NET experts in an informal discussion atmosphere. There will be six (6) discussion rooms each with a separate topic area and multiple experts. Co-host Thom Robbins our local MSFT developer evangelist will also contribute some food, drink, and great raffle prizes.

Got a question you want answered at Cabana Night? Please email it to the experts at ahead of time.

The list of experts confirmed so far includes:

Chris Bowen
Carl Franklin, MSFT Regional Director
Smart Client
Steve Hughes
Robert Hurlbut
Patrick Hynds, MSFT Regional Director
Andy Kelly, MSFT MVP
Duane Laflotte
Jesse Liberty
Chris Pels, MSFT MVP
Thom Robbins (MSFT)
Raheel Retiwalla (MSFT) Database
Richard Hale Shaw, MSFT MVP
Don Sorcinelli
Joe Stagner (MSFT)
Pat Tormey
Smart Client
John Watson

For more information and registration, visit the Microsoft Events web site today.

See you there!

Some More Blog Links Added to the Web Site

I have taken the opportunity to update the Links section of this blog with some more good resources for .NET Compact Framework and .NET Framework information –

If you have a suggestion for a good .NET Compact Framework web site or blog, I’d love to hear about it!

FAQ: Installing Applications To Emulators Limitation

I get asked quite frequently if it is possible to set up an emulator image with applications other those being tested in the Visual Studio.NET environment. Most commonly, people want to install a set of applications to the emulator for demonstration purposes or to test interoperability with their application. While the short answer to this is yes, there is a significant limitation.

It is important to remember that the emulators currently available for Visual Studio.NET and the SDKs are not native emulators. They are x86 emulators to facilitate running in the Windows environment. When you build a .NET Compact Framework solution, included in the CAB files is an x86 version of the application. When you deploy to the emulator, the x86 version CAB is deployed (as well as the x86 version of the .NET Compact Framework and dependencies).

Most commercial applications do not ship with the x86 version of the application in the install file. The reason – this is a commercially shipping product, and there is little reason to include a CAB file used primarily for emulator testing and debugging. A quick browse in \Program Files\Microsoft ActiveSync on your desktop will likely discover a lot of ARM processor CABs, as well as a few MIPS and SH3 CABs (for older devices), but not much else.

Your options? You could contact the vendor and ask about an x86 CAB, although they may look at you (or your e-mail) funny. You could also wait until the next release of Visual Studio.NET (aka – “Whidbey”), which will include native emulators.

Hope this helps answer a “frequently-asked question”…

MSDN: Windows Mobile Platform Migration FAQ for Developers

Any long-time software developer typically has at least one “war story” about application compatibility with a new version of an OS. Windows Mobile developers are no exception, especially when moving from the Pocket PC and Smartphone 2002 OSes to Windows Mobile 2003. Fortunately, the Mobile Devices Team in Redmond has recognized that fact and provided a compilation of frequently-asked questions in the Windows Mobile Platform Migration FAQ for Developers –

Windows Mobile™ software is designed to be easily adapted for a wide variety of hardware devices and for a large number of manufactures, mobile operators, and integrators. To create a platform which has a consistent set of features for developers to target, the Windows Mobile platform provides two defined platforms: the Windows Mobile-based Pocket PC and Windows Mobile-based Smartphone. Within these categories the Windows Mobile platform enables OEM and operator customization that creates unique and compelling devices in the market. Our goal at Microsoft is to ensure a consistent experience for developers across all of these devices, such that applications you build on one device and platform (Pocket PC and Smartphone) will work with little to no modification on the next device. Even though we emphasize this goal, there are occasional variations across products and platforms that can cause applications to behave differently between some devices.

To ensure we are providing maximum information to our developer community, this article addresses a few of the most common issues and frequently asked questions (FAQs) around migrating between devices and platforms. We also provide an e-mail alias at the end of this article that you can use to report commonly-occurring issues so that we can add them to this FAQ.

Kudos to the Mobile Devices Team for putting this all together, and for creating the commitment and mechanisms for maintaining this FAQ over time.

Using Command-Line Arguments

During our user group meeting on Wednesday night, Thom Robbins was presenting on using Web services with Windows Mobile. During the meeting, the old “gotcha” for Web services development and “localhost” came up. Essentially, the gotcha is that the Web services URL is stored as “http://localhost…” in the Web services wrapper object (as part of the URL property). This works fine until deployment to the Windows Mobile device, where “localhost” refers to itself and not the machine name hosting the Web service.

Dave Mitchell of Connected Bits was in attendance, and had a really good suggestion – using command-line arguments to avoid this issue (and lots of others, as well).  Dave basically suggested that by trapping for command-line arguments in your code and using a little-used feature in Visual Studio.NET, you could overcome the issue.

To demonstrate what Dave was describing, I built a little C# Smart Device project. The entire project is available (in ZIP format) here.

To start, you will need to modify the Main method of either the initial form class or other class (if so specified) for the application to accept arguments.

Your code (as demonstrated above) should then –

  • Test to see if there are any command-line arguments;
  • If there are, capture the arguments. In my example, I created a text field on the default form;
  • If not, still have some other default to fall back on.

If I were using a Web service, I would likely –

  • Capture the argument (or default) to a string variable;
  • Perform string manipulation to build the Web service URL;
  • Assign the string to the URL property of the Web service object.

Now, for testing purposes, you can actually use a project property to set command-line variables. To do so, go to Project -> Project Properties -> Configuration Properties -> Debugging in VS.NET. Under Start Options, you should see a Command Line property –

Set the property, press OK, and save the project.

When the sample C# project I wrote has the command-line left blank and the application is deployed, it displays the following (as expected) –

When I change the Command Line property of the project to dpsmachine, then the following occurs (again, as expected) –

The nice thing about this is that it can make the development and deployment of the application quite flexible. Once you know the machine name where the production version of the Web service is located, you can create a shortcut on the device that has that machine name as the argument. Of course, you can use an application config file as well, but the ability to alter the command line property for the project while within VS.NET makes this kind of cool 😉

I could see an awful lot of useful ways of utilizing this during app development. Dave did mention using it as a way of easily tracking instances of a single app when doing multi-user testing and demoing.

Kudos to Dave for pointing all of this out at the meeting!

.NET CF “Gotcha”: DataGrid and Data Binding

I responded to a post at the forums this morning regarding a problem someone was having with a .NET Compact Framework DataGrid. I thought it was worthy of mentioning here because I have answered this question before, and it is one of those annoying little “gotchas” that developers often stumble across with the .NET CF, especially when moving to Mobile Device development from the full Framework.

The user had bound a .NET CF DataGrid to a DataSet that was properly populated, but could get no data to show in the grid. The reason – the DataGrid object in the .NET Compact Framework does not support binding to an ADO.NET DataSet. Therefore, this code will not work –

//dsMyDataSet is an ADO.NET DataSet
dataGrid1.DataSource = dsMyDataSet;

Note that this code does not raise an exception; it simply causes no data to be displayed.

The DataGrid does, however, support binding to an ADO.NET DataTable. So, to rectify the situation, try either –

dataGrid1.DataSource = dsMyDataSet.Tables(“Customer”);


//dtMyDataTable is an ADO.NET DataTable
dataGrid1.DataSource = dtMyDataTable;

.NET To Go Mobility Roadshow

When we had the Windows Mobile Developer Day event here in Boston last month, there was great interest from the Mobile Devices group out in Redmond regarding whether or not the event would be successful. They were looking at doing something similar and taking it on the road to multiple cities across the U.S. Well, it appears that things went well enough here to move forward, as Microsoft has officially announced the .NET To Go Mobility Roadshow. The event will stop in 18 cities, starting in Salt Lake City, UT on October 5th and ending in Mountain View, CA on November 10th –

Have you been thinking about taking your code mobile? Did you know you can develop and implement mobile solutions with the development tools that you already know?

The .NET To Go Mobility Roadshow will provide you with the answers to your mobile development questions. Digging into the details, using more code and fewer slides, these technical sessions will show you how to develop and implement mobile solutions using the .NET Compact Framework and languages you are already familiar with.

5:15-6:00 p.m.
Registration and Food
6:00-7:45 p.m.
.NET Compact Framework Overview
7:45-8:00 p.m.
8:00-8:30 p.m.
Moving Forward with Mobile Applications
8:30-9:00 p.m.
Drawing, Q&A, Ask the Experts

You can find out more about the event and register at the .NET To Go Mobility Roadshow home page.

Unfortunately, the roadshow will not be stopping here in Boston, as we basically had the “pilot run” of the event. It’s just as well – I think ours was better… 😉

“Why No Windows Mobile Upgrade?”: A Complex Answer to a Simple Question

Lately, it seems like the most frequently-asked question I receive around Windows Mobile devices revolves around OS updates for the Pocket PC, Phone Edition, and Smartphone. The question always boils down to something like –

“Why does Microsoft not make the OS upgrade directly available? Why do I have to go through <fill in the manufacturer>?”

There is an answer to this question. Usually, however, the answer is either –

a) Way too wordy and technical;
b) Way too “finger-pointing” in nature;
c) Way too “not what you want to hear”;
d) All of the above

I finally decided that I would take a little time to describe the answer to this oft-answered question in a way that overcomes a) and b). I do not think I can do much to overcome c), especially if you are the owner of a Windows Mobile device that has been “orphaned” by a manufacturer. I am hoping that at the least you will have a better understanding as to why the “Microsoft-direct” alternative is not viable.

A Tightly-Coupled OS and Hardware
How many people can remember back to the early PC days, whether it was DOS or early (pre “Plug ‘n Play”) Windows? More importantly, how many of you remember what an absolute nightmare it was to upgrade the OS and discover your hardware drivers no longer worked? For most (myself included), your PC was never upgraded at the OS level until you checked with all of your hardware component manufacturers to get the latest drivers for the new OS. In some cases, the hardware vendors decided not to support older hardware with new drivers, so you had to go out and buy a new replacement hardware piece (I remember this being common with CD-ROMs) in order to upgrade the OS. While this can still happen today, it is far less common.

Now turn to the Windows Mobile platform. When Microsoft completes a new version of or update to Windows Mobile operating systems, it is not really complete. You see, the new/updated version of the OS must be delivered to all of the manufacturers of the devices for customization. Here’s the deal – Windows Mobile hardware devices are very tightly coupled to the operating system. This is similar to the days of DOS and system drivers, but in some cases is actually more severe. Rather than simply providing an updated driver, the device manufacturers must actually integrate directly (and thererfore modify) the operating system provided to them by Microsoft in order to work properly and efficiently.

This tight-coupling of hardware to Windows Mobile operating systems essentially means that Microsoft cannot simply provide a single generic version of Windows Mobile for all Pocket PCs or all Smartphones. The end result would be disastrous.

XIP – Nice In Theory, But…
Some of you may recall that one of the largely-touted advancements in the Pocket PC 2002 OS was the insertion of “XIP” technology. Without getting too wordy or technical (as promised), XIP was supposed to enable Microsoft and/or the hardware manufacturer to update specific areas of device ROM (where the OS is stored) without having to overwrite the entire ROM. In theory, XIP was supposed to enable –

1) A device update of ROM without having to hard-reset a device;
2) Microsoft to provide updates to items in ROM that would never be customized by any hardware manufacturer.

XIP can (and has) actually been used and works. As a real example, my Mitac Mio 8380 Smartphone (running the Smartphone 2002 OS) actually has been upgraded with a number of ROM updates using XIP. I never once had to hard reset my device after applying one of these updates. While XIP could work to solve the “Microsoft-Direct” update, there were several major obstacles –

1) There would need to be a universally agreed-to standard for “what gets placed where” in ROM (for lack of a better term). Microsoft would need to know that a specific location in memory would always contain the same data (regardless of the device).
2) The agreed-to standard would then need to be rigorously self-enforced by the hardware manufacturers.

As far as I have been ever able to determine, neither items 1 or 2 ever really occurred. Even if they had, it must be noted that XIP would only solve updates that were not device-specific; an update to Pocket Word would be possible, but not necessarily to Connection Manager.

What About Plug and Play and Today’s PCs?
Earlier, I mentioned that many of the problems regarding early PCs with regards to the operating system and hardware have been overcome. Much of this has been made possible by creating a layer in the operating system that separates the tight coupling of the OS to the device. While risking an over-simplification, the evolution of the Windows (and other) operating systems to include a “Hardware Abstraction Layer” (or “HAL”) has made it easier to provide OS updates without as much regard for the underlying hardware. This, when combined with a “Plug and Play” specification (this is a standard for creating device drivers, BTW) to hardware manufacturers and the people responsible for writing the device drivers for the hardware, have made OS updates a much more simplified and hardware-agnostic process.

While this may be possible at some future point for Windows Mobile devices, it is not really feasible at this point in time. The reason is quite similar to the early days of PCs, where resources are at a premium. A Hardware Abstraction Layer requires quite a bit of physical space (something that current Windows Mobile devices are still quite limited on) and processing power (again limited). We may very well see this occur somewhere down the road for the Windows Mobile platform, but not today.

Computing Platform or Consumer Appliance?
The last factor that plays some role in why updates are or are not available for a particular device lies largely with the device manufacturers themselves, and is very non-technical. For many manufacturers, the debate rages internally over whether a PDA or Smartphone is a computing platform or a consumer appliance. The difference in how manufacturers perceive the devices makes all of the difference in the world from a business perspective.

To a manufacturer, a consumer appliance is largely considered “disposable”. That is, the product will likely (based on price and changing technology) be replaced within a brief time period (with “brief” being relative and specific to the product and market). As a result, the cost of labor associated with providing an upgrade is weighed against the need for assigning the same resources to similar products that are earlier in their life cycle. In short, manufacturers count on you as the consumer simply buying a new consumer appliance with more features rather than trying to make due with an older product.

Computing platforms have evolved to the point where users expect to be able to extend the life of their product for longer periods of time (thanks to easier hardware replacement and OS advances mentioned previously). As a result, manufacturers (in order to maintain customer satisfaction) have increasingly taken steps to ensure that labor is put forth to ensure greater upgradeability.

Unfortunately, it has become apparent through actions that some hardware vendors have chosen to classify their Windows Mobile products as consumer appliances, if for no other reason than to try to spur continuing sales of newer hardware through older hardware obsolescence.  This holds true for both Pocket PCs and Smartphones (perhaps even more so for the latter, as that has been an industry-wide philosophy for quite some time).

There is really no one-line response to answer the question as to why Microsoft cannot currently simply directly provide upgrades to Windows Mobile devices. It is a complex situation that prevents this from happening today. While it is possible that this situation can change over time, it will only happen if hardware manufacturers buy in to the process. Hopefully, this text has helped explain the situation a bit more clearly.   

Upcoming Event Reminders

Just a couple of reminders for everyone out there regarding upcoming .NET Compact Framework-related events –

  • The next Club Pocket PC – Boston group meeting is this Wednesday, October 15th. Thom Robbins will be doing a presentation on Windows Mobile and Web services, and I will be presenting / demonstrating a fantastic utility for Windows Mobile developers and support personnel in SOTI Pocket Controller. You can find out all of the details at
  • Registration is still open for the Cabana Night at the Microsoft -Waltham offices on October 5th. This looks to be a lot of fun, with an incredible number of experts in each of the individual rooms. Remember – this is a “no-seminar zone” (fortunately, Chris Pels has not trademarked this phrase – yet). The discussions are more free-form, and you are encouraged to come loaded with questions and discussion points. You can find out more about the event and register at the Microsoft Events web site.

Creating “Reusable” Applications Between Platforms

I was once again engaged in an e-mail conversation this past week regarding the cross-platform compatibility of .NET Compact Framework applications. In this case, I was asked about the portability of an application developed for Windows CE.NET to Windows Mobile.

Generally, I respond to these types of questions with “Realistically, no.” While I know there are certain technical exceptions to this rule, the best realistic answer is that the compiled code is not portable. There is something that you as the developer can do to maximize the portablility of your application logic. Simply follow these steps (easier said than done for some) –

1) Separate your application logic from your user interface logic when designing and developing your application. Use classes to create all of the non-UI logic for your application.

2) Test your code on the first platform and make certain all is as desired.

3) Create a new project for the next platform you wish to target.

4) Copy the source files for the non-UI logic you created for the first platform.

5) Design the UI portion of your new project.

The bottom line – even if compiled .NET CF logic was portable between platforms, the UI presentation and user interaction for each platform has enough uniqueness to compel you to develop the UI portion to meet the unique demands.

On a side note, the latest version of Windows Mobile (2003 SE) presents a case for potentially designing different “versions” of an application within a single target platform. The SE version of the OS natively supports both landscape mode and VGA. This can have an undesirable effect on UI presentation of applications. For more information on this, you can check out my presentation on this subject, available for download in PDF format here.