One of the issues you might run into if you are creating your own User Controls for a Windows Mobile application is a poor designer experience in Visual Studio 2008. This will happen if you are making use of specific Windows CE or Windows Mobile functionality that is not supported on the desktop. The reason is that Visual Studio in designer mode does not have any knowledge about the target platform, so it needs to make use of functionality that is available on the development machine, and it will target the full .NET Framework. A typical example of poor designer experience occurs if your control is P/Invoking to a native Win32 API. In Windows CE, Win32 APIs usually live in different DLLs then their desktop counter parts. Take the following example of a User Control that wants to display a gradient background. The control is a GradientButton and it takes care of its own painting functionality:

When running on a device, a test application displays the button(s) and also a GradientLabel that is derived from the same GradientControl base class as expected. However, when creating the form you will not have a great designer experience, since the controls are not rendered the same way as they are on the device. Without doing anything, this will be the default designer experience:

Showing the User Controls as Visual Studio 2008 does is a pretty safe solution. Since User Controls might use (drawing) functionality that is exclusively available on the device, the decision of the Visual Studio is to just display a place holder for the control with the correct dimensions. Sometimes this might be sufficient, but what if you want to get a real WYSIWYG designer experience? By making use of designer attributes, which should be defined in a separate XMTA file (that defines designer attributes in XML), you can specify that your control is desktop compatible. What you are saying in that way is that you know for sure that Visual Studio’s designer should be able to render your User Control correctly. Adding <DesktopCompatible>true</DesktopCompatible> to my XMTA file (for both the GradientButton and GradientLabel) results in the following error message (one for each control on the form):

And, after acknowledging the error messages, in the following designer experience:

This experience is worse than the original way the designer showed our form. The problem that we encounter in this particular situation is the way the User Controls are painted. To paint a control with a gradient background, we need to P/Invoke to the native GradientFill method, that is defined in the managed control library in the following way:

The problem however is that, even though Windows 7 (as target operating system for Visual Studio 2008) has a GradientFill API, it is not defined in a DLL called coredll.dll, but instead, it is defined in a DLL called Msimg32.dll. To force Visual Studio to make use the GradientFill API from the latter DLL, we can make use of conditional compilation. Suppose we would change the P/Invoke declaration to the following and make sure that DESIGN_MODE is set, we should have a great designer experience:

However, in this situation you need to make sure that you undefined DESIGN_MODE prior to deploy the User Controls to the device. If you forget to do this, you will get runtime errors when running your application that makes use of these controls on the device. To limit possible runtime or design time errors, what you can do is make use of a new Build Configuration in Visual Studio. That is exactly what I did for this Control Library. Using the Configuration Manager I created a new configuration called DesignMode that is based upon the original Debug Configuration. I made sure to set uncheck the Deploy checkboxes in this configuration, resulting in a DesignMode build that will never be deployed to the device.

Additionality, in the Project Properties of my Control Library I defined the conditional compilation symbol DESIGN_MODE only for the DesignMode configuration.

Working with different configurations is great in this particular situation. Each time I want to open the form in designer mode, the first thing I am doing is changing to the DesignMode configuration. As a next step I rebuild my entire solution. After this, it is safe to open the form in the Visual Studio 2008 designer:

Once I am done modifying the form, I make sure to close the designer window inside Visual Studio 2008 for that particular form, change the configuration to either Debug or Release, rebuild the entire solution and after that, deploy the modified application to a target device. As you can see, there are a few steps involved to get a relatively acceptable designer experience when working with non standard controls, but for me, these extra steps are definitely worth investing in. After all, taking these extra steps I will get a WYWIWYG experience prior to deploying my application to a device or to the device emulator.