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.


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

Old New
ToolBar ToolStrip
MainMenu MenuStrip
ContextMenu ContextMenuStrip
StatusBar StatusStrip
DataGrid DataGridView

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.

Comments (5)
  1. Anonymous says:

    Migrating from WinForms 1.0 to WinForms 2.0

  2. Anonymous says:

    Ashutosh Nilkanth’s Blog » Windows Forms 2.0

  3. Anonymous says:

    i like winforms 2.0 :>

  4. Anonymous says:

    1. DateTimePicker is still useless and should not be allowed to be released in this horrible state with no nullability.

    2. Combo/Listboxes still don’t do linked lists (i.e M = Male, F=Female) This was in VB6 and is in ASP.net, but we can’t have it in Winforms? These controls are entirely useless for anything but bound data lists because you rarely if ever store the text in the combo to the database, it’s almost always a tinyint or a char. Put back the functionality that you took away from VB6!

    3. The MDI Parent bugs (see my posts in the winforms beta news group) are still there after 1 versions of .NET and MUST be fixed. In two cases there are no work arounds.

    4. The tooltip’s balloon control makes no sense. The icon and title are set globally. If you think about this at all, you’d realize that it should be per control, not per tooltip because the title is always going to be specific to the control that you’re hovering over. Whoever wrote this and didn’t notice this fundamental design flaw… wow.

    Other than no useable combo control still, no usable list control, no usable datetimepicker and no usable balloon tooltip control and a host of MDI bugs that cause havoc, Winforms 2.0 is great! Yes, it’s an improvement on .NET 1.1/1.0, but I’m still going to have to buy third party controls for basic things like combo controls and date pickers, so I fail to see the usefullness. All of the above should be fixed (and I’ve been told that none of them will be!).

    There’s no excuse for this crap to make it through 3 versions. Hell the date time picker problem is 3 versions of .net and 6 versions of VB!

  5. VDeevi says:

    Can we able to migrate MS-Access application(having forms, reports etc) to WindowsForms 2.0. If it is possible please kindly provide the procedure or method of migrating to WindowsForms 2.0.



Comments are closed.

Skip to main content