WinForms to Web: Migrating Desktop Applications, Part 1
This is the first part of a series of articles that describes the various migration options of desktop/smart client applications to the web available using Visual WebGui.
To discuss the migration process of legacy desktop applications to the web, you should first be aware of three different types of desktop applications:
- WinForms-based desktop application (C#/VB.NET): The UI layer is coded using .NET languages—the business can be .NET, COM+, or any other interop.
- VB 6.0-based applications: The UI layer is coded with VB 6.0.
- Smart client or other desktop technologies (C++ MFC/ATL, Delphi, Java, and so forth): Any other smart client technology based applications.
This document describes the migration process of WinForms-based desktop applications to the web using Visual WebGui.
WinForms-Based Desktop Applications: Background
Normally, without Visual WebGui the migration process of a WinForms desktop application to the web will require a full re-engineering of the UI layer to fit the web architecture and capabilities.
If you take WinForms migration to ASP.NET, for example, using any AJAX third-party controls to provide a rich UI experience, you will have to consider:
- Entirely new API.
- Entirely new update approach.
- Entirely new look & feel—or work hard to customize the UI to look the same.
- Lighten the amount of data transferred to the client and presented at any given time to avoid severe latency.
- Compromise on features list due to the web limitations.
- Handle security holes created as a result of opening services consumed by client-side AJAX and transferring business logics to the client.
The Visual WebGui SDK is fully integrated with Visual Studio and provides the exact same API and set of tools/capabilities that are provided out of the box with WinForms 1.0 and 2.0. This fact enables the native capability of simply copying any existing WinForms source code to a VWG project and providing a fully functional equivalent web application.
The three basic steps of migration (view a walkthrough tutorial):
- Open a new Visual WebGui application.
- Copy the code from your WinForms project into this new web application.
- Replace any reference to the WinForms API namespace (“System.Windows.Forms”) within the code to Visual WebGui API reference (“Gizmox.WebGUI.Forms”).
Any standard WinForms application that uses the 58 WinForms out-of-the-box controls will then compile and execute as a plain web application.
The outcome of this short process is an ASP.NET-based solution in terms of deployment and runtime and has the following properties:
- Deployment is a copy & paste equivalent to an ASP.NET web site.
- Server infrastructure requires an IIS and .NET CLR only.
- The application can be consumed from any plain browser—no installation is made on the client.
- Minor static and cached footprint on the client— ~200kb of plain JS and HTML code due to the Empty Client concept.
- Support for multiple presentation layers with the same code base (DHTML/Silverlight or Smart Client).
- Highly secured due to the Empty Client concept.
Considerations & Exceptions
There are three major setbacks you might have during the process that you can quantify in advance and estimate the amount of work that has to be done to migrate your application:
- Minor differences between the VWG API and WinForms that are mainly caused by architecture differences.
- The amount of third-party controls that are used in your application. This section describes a situation of using some non-WinForms out-of-the-box controls (for example, Infragistics or DevExpress controls, and so on). In those cases, you can select the most suitable solution from the following three options:
- Choose a similar control from the WinForms out of the box, adjust your code to use it, and then perform the migration process.
- Select an equivalent third-party ASP.NET control (Infragistics, Telerik, DevExpress, and the like) that provides the same functionality, wrap it by a click of a button in VWG, and adjust your code to use it.
- Write your own VWG custom control that will perfectly suit your needs and then adjust your code after the migration process to use this control.
- Adjustments of a single-user desktop application to a multiuser web environment. This section summarizes some of the major issues of transforming a single-user application to a multiuser application sharing the same CPU, memory space, and other resources.
- Thread safety: Because a WinForms application can contain static members that are accessible to a single user, you should now consider one of the following:
- Replacing those static members to synchronized multi-thread safe data structures.
- Lock critical read/write sections to protect concurrent multi user access.
- Remove the statics and find an instance or DB-based solutions.
- Memory load: In a desktop application, there might be places when the original consideration of the amount of memory in use was based on the assumption that the executing machine is local. Therefore, many items are loaded to memory simultaneously without limitation. Now, on a shared memory environment, when the server does the heavy lifting, the amount of memory consumed by each user will set the number of concurrent users that can be served by each server.
The following steps are recommended:
- Consider loading items to memory on demand (keep only the headers and the identifiers in memory).
- Remove any large objects read to memory. For example, don’t save binary objects to memory; instead, write the binary to the response stream directly to the client.
- Prefer DB-based paging on entire prefaces and memory-based paging. Visual WebGui provides mechanisms to enable it easily.
Migration of any WinForms application to the web using Visual WebGui has the following advantages:
- In three simple steps, you will be able to get very close to a working web application.
- The effort you have to make to accomplish a fully functional web application is measurable.
- The application can keep using the existing BL and DL layers; only the UI is either migrated automatically or adjusted.