By Greg DeMichillie [Bio]
Posted: Jul. 22, 2002

• Illustration: User Interface Improvements in Windows Forms
• Illustration: Configuring .NET Applications

Windows Forms, the new user interface (UI) class library included in the .NET Framework, allows developers who have previously abandoned thick-client development, due to difficulties in deployment and maintenance, to make client development decisions on a case-by-case basis. By providing a common set of UI components for all .NET developer tools, Windows Forms makes the best aspect of Visual Basic (VB)—its ease of UI development—available to the entire .NET platform and at the same time addresses some of these longstanding deployment and maintenance problems. However, some limitations remain, including a lack of support for platforms other than Windows.

Although the thick-client architecture (in which application-specific code runs on and processes data on the client, rather than merely rendering data which has been processed by a server) was once the norm, the Internet has popularized the thin-client model, in which a server application is accessed through a standard Web browser and the bulk of the processing takes place on the server. Because Microsoft derives a significant portion of its revenue from selling the desktop operating systems on which thick clients run, it has a vested interest in making thick clients as attractive as possible. This has forced the company to address some of the longstanding deficiencies of its thick-client architecture, and Windows Forms represents a significant step in that direction.

One-Size-Fits-All Doesn’t Work

The introduction of VB in 1991 dramatically simplified the process of developing thick-client applications. At the core of the VB programming model is the concept of "composition"—that applications can be created by taking prewritten UI components such as list boxes or buttons (usually referred to as controls), placing them on a design surface (usually referred to as a form), and then writing a small amount of custom code that "glues" the controls together and is invoked when a user interacts with a control. But as VB applications grew more complex and used more controls (developed both by Microsoft and third parties) the limitations of Microsoft’s thick-client architecture became clearer: applications were difficult to update over time because components were shared among multiple applications, and because component creators were unable to maintain complete backwards compatibility.

As a result, many developers adopted the thin-client model of application development. Placing the application code on the server, instead of on each client, greatly simplified updating applications, since the server was a controlled environment (reducing the amount of unknown software that could potentially cause conflicts). In addition, deployment is much easier because the code could be updated in a single location and made instantly available to all users of the application.

Nevertheless, the thin-client architecture has its own problems. Thin-client applications place more of the processing burden on servers and fail to take advantage of the often-unused computing power available on today’s PCs for tasks such as sorting, filtering data, and generating charts and graphs. In addition, thin-client applications are unsuitable when users must work offline. Users of a sales-force automation application, for example, might want to update customer contact information while on an airplane, but they would be unable to connect to the server portion of a thin-client application.

Addressing Problems of Thick Client

Contributing factors to the widespread adoption of thin-client development were the deficiencies of both Microsoft’s underlying thick-client architecture (Windows and the Win32 API) and the tools used to develop thick-client applications (including VB, VC++, and third-party tools). The .NET Framework, which includes the Common Language Runtime (CLR), makes thick-client applications more attractive by making them more reliable, easier to deploy, and easier to localize, as well as adding new capabilities, such as advanced graphics. For more detailed information on the CLR (such as how it improves application security), see the Feb. 2002 Research Report, "The .NET Development Platform."

More Reliable Execution

When a thick-client application is installed on Windows, it often breaks existing, unrelated applications on the same client PC. This fragility is due to the pervasive use of shared dynamic-link libraries (DLLs), used by Windows to package and distribute components and to allow them to be shared among multiple applications. The original designers of the DLL architecture made the implicit assumption that sharing components is better than having multiple copies, and that a newer version of a component is always better than, and completely compatible with, older versions of the same component. But as the complexity of components increased, those assumptions proved to be incorrect. Applications often relied on undocumented (or even incorrect) behavior of a component, causing them to function incorrectly when a newer version of the component was installed.

The .NET Framework and Windows Forms make no such assumptions. By default, .NET applications (and components) are isolated from other applications on the system. Developers and administrators both play a role in determining the "binding policy" for an application—the rules that determine which components are used by any given application. When creating an application, a developer specifies the components it will require. By default, the application will require the exact version of the component used by the developer, but administrators can change the binding policy by specifying how the system maps version numbers requested by the application to version numbers installed on the system. (See the illustration "Configuring .NET Applications" for an example of the configuration tool.)

Easier Deployment

The .NET Framework also eases the process of installing a thick-client application. Installing applications built with Microsoft’s previous thick-client technologies (VB6, most commonly) can be troublesome. Each component used by an application must be properly registered on the client machine for the application to be able to locate it. In addition, each application must participate in maintaining a count of the number of applications that rely on each shared component, so that the application and all related components can be completely removed at a later time. Failure to maintain this count correctly can lead to components being deleted when one application is removed, even though the components are still required by other, still installed, applications.

Even though (in most cases) .NET applications that use Windows Forms must still be copied to the client machine, the process is simpler because components can simply be copied to the same directory as the application without any registration or reference counting. When the application is removed, the components upon which it relied are deleted as well.

Support for Localization

Many developers, particularly independent software vendors who sell their applications worldwide or internal IT developers at multinational corporations, need their applications to be localized for different countries. This frequently involves more than just translating the text of the UI. Other changes might include the size and position of elements of the UI (many words in German, for example, are significantly longer than their English counterparts); the symbols used for currency; and the sorting order for text.

Ideally, the process of producing localized versions is isolated from the source code of the program so that translators do not have to be developers and can work without fear of accidentally altering the behavior of the program.

Since its inception, Windows has included the concept of "resources"—elements of a program other than the code, which can be modified independently of the code. But these resources are ultimately stored in the binary executable of the program and are difficult to edit, making it difficult for translators to work independently of the development team.

Windows Forms places all data requiring localization in XML files (one for each locale the application will support) that are separate from the source code. During the process of compiling the source code to a binary executable format, these XML files are translated to "Satellite Resource DLLs." (In addition, Visual Studio .NET supports creating, editing, and compiling these files.)

When the application starts running, Windows Forms determines the locale setting that Windows is using and automatically loads the appropriate Satellite Resource DLL, simplifying the process of creating a single program that works correctly worldwide.

Building Better User Interfaces

Prior to the introduction of the .NET Framework, Microsoft’s developer tools were divided into two groups. On the one hand, Visual C++ (VC++) had access to the complete set of Windows APIs but was aimed at developers building lower-level components. On the other hand, VB took a limited set of Windows APIs and made them more accessible to business developers. As a result of this division, many of the new capabilities introduced in Windows in recent years, such as 3D graphics, have been available only to developers using C or C++ and were therefore beyond the reach of many business application developers.

Windows Forms provides a common UI library for all developer tools, a library that attempts to combine the ease of development of VB6 with the support for the complete Windows platform of VC++. The result is that both VC++ and VB developers will find that Windows Forms includes built-in support for UI features that previously would have required custom code. Some of these new UI capabilities include the following:

Resizable forms. Despite the fact that Windows has allowed users to resize forms or windows, Microsoft’s developer tools provided no support for creating forms that resize intelligently. When a user resizes the windows of an application built with previous versions of Microsoft’s developer tools (such as VB6 or VC++ 6), the window gets larger but the controls simply stay where they were, unless the developer wrote precise and complicated custom code to move and size the controls. Because it was very hard to get the behavior correct in all cases, hardly any developers attempted this. Windows Forms provides a way for developers to easily create applications that automatically adjust the size and location of controls as the application window is resized. (For an example of a Windows Form application that intelligently resizes itself, see the illustration "User Interface Improvements in Windows Forms".)

Advanced graphics. The graphics capabilities of Windows have advanced dramatically in recent years with the addition of hardware acceleration for 2D and 3D graphics. Although it is easy to dismiss such capabilities as unnecessary in business applications, in fact these capabilities are frequently used by independent software vendors to produce commercial software. However, they have only been available through the games-oriented DirectX APIs.

Windows Forms combines these capabilities into a single class library usable by business application developers or commercial software vendors. Including support for DirectX capabilities in Microsoft’s mainstream development tools will allow business applications (such as geographic information systems) to incorporate more sophisticated graphics and could encourage developers to use development tools other than C++, which in the past was the only tool able to access technologies such as DirectX.

Accessibility. Windows Forms also incorporates support for Microsoft Active Accessibility (MSAA), a set of APIs designed to help accessibility aids (such as text-to-speech software or Braille display devices) interact with standard and custom UI elements, thereby making software more accessible to users with disabilities. Support for MSAA allows accessibility aids to query Windows Forms applications for information (about the UI element at a given screen location, for example), to receive notifications when information changes (when a control becomes grayed, for example), and to carry out actions that affect the UI (clicking on a button, for example).

Some Limitations Remain

Although Windows Forms addresses some of the well-known limitations of using Windows as a thick-client platform, it is not cross-platform, it does nothing to solve difficulties such as updating an application once it is installed, and developers must still write significant code to allow an application to work offline.

Not Cross Platform

Although Microsoft and third parties have indicated that portions of the .NET Framework will be available on other platforms, it is extremely unlikely that Windows Forms will ever be available on non-Windows platforms.

Its goal was to take the existing client APIs of Windows, along with the newer graphics capabilities of DirectX, and make them easier for developers to use. Because its internal implementation relies heavily on Microsoft’s proprietary Win32 APIs to obtain the best performance and most features possible, it is not and was never designed to be cross-platform.

Updating Still Hard

Once an application and its associated components are installed on a client system, administrators frequently need to update specific components in order to fix bugs discovered after the application was deployed. In many cases, the administrator and developer would like the application to automatically update itself each time it is started, thereby insuring that it is using the most up-to-date components available.

Unfortunately, although the .NET Framework includes all the capabilities necessary for an application to identify the components it is using, query a server for updates, and download newer components as required, it does not include any prewritten code to simplify the process or guide developers in using the features appropriately. It is possible that a future version of Windows Forms will include better support for auto-updating applications. Until then, Microsoft has only made available unsupported sample code that demonstrates how to build such an auto-updating application.

Off-Line Not Automatic

In addition to Windows Forms, the .NET Framework includes ADO.NET, a class library for accessing information stored in databases. It supports caching the results of queries and making those results available when the application is no longer connected to the database. Such offline support, however, is not automatic: the application must detect when it is disconnected and take appropriate action (e.g., working from the offline cache).

In addition, working offline means developers must write code to resolve any conflicts between changes made to the offline cache and those made by other users to the online database. (For more information on ADO.NET and the offline capabilities of the .NET Framework, see "ADO Redesigned for Web Architecture" on page 10 of the May 2002 Update.)

Recommendations

Because neither thick-client nor thin-client is universally appropriate (despite the rhetoric from companies with vested interests on either side of the issue), developers who have moved away from thick-client strategies should make decisions on a case-by-case basis as they develop new applications.

The following factors must be considered when deciding between thick-client and thin-client architectures:

Frequency of use. Applications that are used infrequently are good candidates for thin clients. Building, installing, and maintaining a thick client just isn’t worth the effort if the application is only used once a month to view a sales summary, for example. On the other hand, if the application is used by telephone sales staff every day to enter customer orders, then the slower response of a thin-client application might not be acceptable.

Degree of user customization. If the basic nature of the application is to produce the same data for all users, then a thin client is often the best choice—even if the application is used frequently. When multiple users are requesting and viewing the same information, a server can often cache the results efficiently, rather than downloading the data to each individual client for local processing. But thick clients that can process data locally become more attractive as the degree of user customization increases.

Support for mobile users. If the application is used by mobile users who need to view data while disconnected from the network, then a thick client with offline support is the only reasonable option. In contrast, if the application is used by mobile users who access the application at different times from different devices, but always while connected to the network (from Internet-enabled cell phones or public Internet kiosks, for example), then thin client may be a better choice.

Management infrastructure. The presence of a software management infrastructure, such as Microsoft’s System Management Server, simplifies the deployment of thick-client applications because the installation can be invoked automatically without user intervention. Companies without such an infrastructure may find the centralized management capabilities of thin-client applications more compelling.

Resources

For an overview of the entire .NET Framework and associated APIs, see the Feb. 2002 Research Report, "The .NET Development Platform."

The Windows Forms development team publishes articles and other developer information at www.gotdotnet.com/team/windowsforms.

Although Windows Forms is a relatively new technology, some books on the subject are available:

Windows Forms Programming with C# by Erik Brown (ISBN 1930110286) is a fairly thorough coverage of Windows Forms aimed at the beginner to intermediate level programmer, and although the examples are in C#, the information on Windows Forms is applicable to VB programmers as well.

User Interfaces in VB.NET: Windows Forms and Custom Controls by Matthew MacDonald (ISBN 1590590449) covers Windows Forms for the more experienced VB developer. A C# version by the same author will be published in Aug. 2002 (ISBN 1590590457).

Finally, for those programmers who have been creating Windows applications long enough to have cut their teeth on Charles Petzold’s classic books, his Programming Windows with C# (ISBN 0735613702) offers 1,200 pages devoted to building user interfaces with Windows Forms.