Migrating from Windows Forms 1.x to Windows Forms 2.0

This entry starts by looking at the new features in Windows Forms 2.0, and then proceeds to describe the migration strategy for existing Windows Forms 1.0 applications that are to be migrated to .NET Framework 2.0.

New Windows Forms Controls

We've added some new controls to Whidbey:

• MenuStrip / ToolStrip (for professional toolbars and menus) with advanced rendering capabilities to allow you to render for Office and also an extensibility model to allow you to supply your own custom rendering. Can add standard items.
• StatusStrip: a control similar to the V1 StatusBar control but more panel-orientated.
• DataGridView control: supersedes the old DataGrid control, and allows for easy binding to conventional data sources, web services or even business objects that support enumeration.
• DataConnector (used to be called DataContainer): a helper for binding data to multiple controls.
• SplitterContainer, a much improved version of the splitter control that automatically creates panels above/below or left/right of the splitter for ease of development. A lot of the issues with the old control (being invisible, auto-docking to the left hand side of a form) have been fixed.
• WebBrowser: an in-built container for Internet Explorer
• MaskedEdit: a masked-edit control somewhat like the old VB6 masked edit control but with greater flexibility and affinity to the TextBox control.
• TableLayoutPanel and FlowLayoutPanel: matching the HTML model where sometimes you want to add controls in a forms model so that as your page resizes (or during localisation), the controls do the right thing and lay themselves out appropriately without manual intervention. Great for business forms.

Other WinForms Improvements

• Client configuration: XML-based model for saving the state of your application into the system. You can select any control that you want to be persisted, and bind it to an application setting. Select the control, navigate in the Property window to ApplicationSettings/PropertyBindings, and map the control to a setting. Unfortunately you still have to write the glue code to physically persist it (e.g. to a registry or a config file).
• A BackgroundWorker component that provides asynchronous programming on a background thread with communication forward to the UI thread to update progress. This makes a difficult job much easier (see Chris Sells' canonical articles for advice on how to do this today in Windows Forms 1.0).
• Improved printing API

Deployment Improvements

ClickOnce, a no-touch deployment and update mechanism for rich client applications. You can create a ClickOnce application through the Publish Wizard, which publishes an application to a URL. You can choose whether the application is available in online/offline modes or only whilst online. This has nothing to do with the functionality of the application, but it allows you to choose whether the shortcut to the application is in the start menu or as a URL. Publish Wizard allows you to sign the deployment manifest with a key, so that only the application publisher can make modifications to the application. The wizard copies all the files and the deployment manifest to a location (typically a URL). By default applications are set up to require full trust, but you can modify them to use a lower trust model. If necessary, the application prompts users for permissions to install the application if it requires a higher level of trust than would otherwise be granted to it.

Designer Features

• Smart Tasks: designed to make common tasks more straightforward - a little like Smart Tags in Office XP and 2003;
• Designer layout assistance and usability: blue line means that the bottom is aligned; red line means that the text is aligned (useful for textboxes). Dotted lines between label and control when they are at the "standard" space as matches the UI guidelines. Also applies when you move a label to the edge of a form.
• Hide initialize component: as well as partial classes to hide the code (Form1.Designer.cs), we also create a separate Program.cs file with the program stub (static void Main(), containing the Application.Run(new Form1()) invocation);
• User control container: you can create a user control project and run it directly without having to create a test harness first.

Migration

The good news is that you can take any WinForms 1.x application and use it unchanged in the Whidbey environment using the existing controls. When you open a WinForms 1.x solution in Visual Studio 2005, the Visual Studio Conversion Wizard will kick in and offer to convert the project and solution files across to the new format, but it will leave the code completely intact. The old controls still exist, but are deprecated: for practical purposes, that means that they are not visible from the toolbox, but are available.

The bad news is that if you want to migrate a WinForms 1.x application to utilise 2.0 functionality today, you'll have to do a little work by hand. There are some controls that are fairly easy to upgrade (e.g. StatusBar -> StatusStrip), but others that are much harder (e.g. DataGrid -> GridView). One approach to see the changes between the controls is to compare the output from the designer tools. For example, toolbar separators are treated as a special kind of button in the ToolBar control, but exist in their own right as separate controls in the ToolStrip. These minor changes should be fairly easy to fix with search and replace or a sed-style script, however.

A Comparison of Old and New Controls

One thing to bear in mind is that the DataGridView does not include support for hierarchical tables, something the old DataGrid was good at doing.