Page 1 of 2   next page »

This article describes a pattern that allows any Web site or Web application to launch and interact with .NET 2.0 Windows Forms applications that are deployed using Microsoft's new "ClickOnce" technology. This is done by taking advantage of a feature that allows Windows Forms applications that are deployed using ClickOnce to receive querystring parameters.

Background: "ClickOnce"
Many people who work in business software development cringe when they think about large-scale deployment of Windows Forms applications. New versions of a desktop application must be deployed in controlled patches. Thus, distribution of a new application to multiple offices of a national or international corporation can be a major logistical undertaking. When Web-based applications arrived on the scene, they were hailed as the perfect response to these problems. They provided ease and convenience at deployment time.

Over time, Web UI and functionality has improved. However, there is one place where Windows Forms applications are vastly superior. The user interface can be tuned, customized, and made extremely efficient. A Web application is always going to require more mouse clicks and key presses for a business user to perform their job than a custom Windows Forms application with its infinitely customizable hotkeys and UI layouts.

The release of Visual Studio 2005 and .NET 2.0 is a major shift back to Windows Forms. Microsoft's new Windows Forms deployment technology, ClickOnce, is targeted expressly at eliminating the drawbacks of Windows application deployment. This technology automates the deployment process and ensures that all users are running the same version of the application. IT departments can deploy software and patches to one central server just as they have done with Web applications in the past.

ClickOnce Makes It Much Easier to Deploy
Microsoft's ClickOnce FAQ states, "'ClickOnce' is the codename for a technology that ships in the .NET Framework 2.0 that allows Windows Forms-based client applications to be downloaded and run over the Network. Quite simply, ClickOnce makes running a client application as easy as clicking a link in a web page."

It works like this: developers "publish" a Windows Forms application to an IIS server and specify any prerequisites, assemblies to include, and deployment preferences. End users can then go to a Web page or hyperlink and initiate installation or update from the published location. Subsequently, each time the application starts it contacts the IIS server to make sure that it has the latest version of the program.

There are a number of nice options and features built into ClickOnce. After the application has been installed the first time, a start-menu shortcut can be made available. Applications that are capable of working offline can be configured to operate without being connected to the network. Control of which software version updates are applied can be controlled centrally or left up to the end user. Also, parameters can be passed from the IIS server link through to the Windows Forms application.

Years of Legacy Web Applications Can't Be Replaced All at Once
With ClickOnce, the logistic difficulties of Windows Forms application deployment have clearly been addressed. In many cases, however, companies may still be hesitant to introduce new Windows Forms applications in an existing environment. After the internet and technology boom of the late 1990s, it seems likely that a majority of medium-to-large companies have important operations that depend heavily on Web technologies.

Much of money and time has gone into existing Web applications built using ASP/COM, and more recently, ASP.NET technologies. These applications have been finely tuned over the years and frequently serve as the primary interface for business-critical software systems. In many cases, the performance and reliability of these applications is more than acceptable, so there is no justification for replacing them.

When planning the construction of a new software system or user interface however, it is preferable to utilize new technology. There are many advantages to migrating to a .NET 2.0 and Windows Forms technology base. .NET has a proven track record of reducing development times and costs, and it has been improved even more for performance, scalability, and reliability with version 2.0. In addition, this technology has a large user community and will be supported for many years to come.

The Problem: Launching Windows Applications from the Web Is Not Easy
The Windows operating system and browsers that run on it have been expressly designed to prohibit Web pages from launching Windows executables. This makes a whole lot of sense - it's not hard to imagine the damage that could be done if any Web site or even banner ad could launch a command prompt and start entering commands!

Anyone who has tried to configure a Web site to communicate with a client's machine knows that the security is very tight. It's not possible to execute code on a client workstation from a Web application without physically modifying the application security settings on the client machine to specifically allow it. Moreover, it is even more difficult to configure a Web application to interact with an instance of an application already running on the client machine. The client application will be running in a separate process than the client-side portion of the Web application.

It is, of course, very desirable to strictly control the access that Web-based programs can have on a client machine. Bypassing this security obviously introduces a significant degree of risk, and while it can be mitigated by signing assemblies and only allowing specific code to execute, there is still a loosening of security rules that should be avoided in most cases. Basically, while it may be acceptable for a few specific implementations, once loosening of security becomes the general architectural rule for enterprise development, the chances increase that security holes will be introduced.

The Solution
The following sections will walk through the process and provide a simple example of this integration pattern. The goal of this example application is for a simple HTML page to send information to a Windows Forms application. If the Windows Forms application is not running when the ASP page initiates the link, it will start up and have to display the parameter values. If it is already running, it will receive the information and refresh its display with the parameters sent in.

Create the Windows Forms Application
Open Visual Studio 2005 and create a new Windows Application. This example will use C# syntax. Name the project ClickOnceWindowsFormsApplication, and change the name of the default form from "Form1" to "ExampleForm." The interface will be very simple: open ExampleForm in the designer and add a ListBox to it. Rename the ListBox "listBoxParms." Figure 1 shows the form layout as it appears in the designer.

The code of this form only needs two modifications. First, create a private member to hold the string array of parameters that will come in from ClickOnce.

private string[] _parmArray;

Second, create an overload of the Form.Activate() method that accepts a string array as a parameter. This will be used by the application to send the parameters it receives from ClickOnce up to the form. Listing 1 shows the code for this Activate method overload. It simply calls Activate() on the base class, copies the parameter to the local _parmArray variable, and binds the ListBox to _parmArray.

Program Modifications
In order to have the application (represented by the class "Program") run as a single instance that responds to parameters from ClickOnce, it must be modified in several ways. First, it needs to be changed from the default static "window launcher" into an object that represents the running application, and therefore is instantiated and has state. In this example this will be done by changing the static Program class to an instance class that inherits from Microsoft.VisualBasicApplicationServices.WindowsFormsApplicationBase. This base class provides a lot of handy event handlers and properties for Windows Forms applications. To inherit from this class, add a reference to the .NET assembly Microsoft.VisualBasic, and change the class declaration of Program to read as follows:

public class Program : WindowsFormsApplicationBase

Next, modify the Main() method to handle the parameters coming in from ClickOnce. ClickOnce URIs that use HTTP have the following basic format: "http://<published location>/<application name>.application," where <published location> represents the location of a directory served by IIS. Parameters can be appended to the ClickOnce URI using the same syntax as HTML querystrings. An example of a "ClickOnce" URI with parameters might look like this:

http://MyServer/MyApp.application?parameter1&parameter2

Listing 2 shows the modified static void Main method. It extracts the parameters by retrieving the URI that was used to launch the application, splitting the query portion of the URI on the "&" symbol into a string array, and passing this array along to a new instance of Program. From this point forward, parameters are in a string array and are treated as command-line parameters.

Page 1 of 2   next page »