Windows Forms applications have two major disadvantages compared to technologies such as ASP.NET and Web Forms that can deliver user interfaces via the browser: cross-platform support and deployment issues. .NET goes some way to addressing these “Web vs. Windows” problems; third-party .NET implementations such as Mono (http://www.go-mono.com/) and
DotGNU (http://www.dotgnu.org/) allow Windows Forms applications to be run on a wide variety of platforms, and the deployment model of .NET improves with each new version of the .NET Framework. This section won’t cover deployment in detail but rather will provide a short glimpse of the ease of Windows Forms deployment offered by a new technology in .NET 2.0 called ClickOnce.
Before covering ClickOnce, though, it’s worth briefly discussing desktop application deployment through the ages. The first Windows applications didn’t require much in the way of installation—they could be simply copied to some location on the hard drive or run from a floppy disk. To provide a simpler experience for newer users, installation programs that added shortcuts that allowed the application to be launched without navigating to the EXE file became popular. With Windows 95, the registry replaced INI files as the preferred location to store configuration data, and installers generally added a number of registry settings. As more features were added to Windows, installers became more complex in an attempt to deal with these features; dealing with COM registration, MDAC versioning, event log sources, and COM+ applications all became part of the installation activities.
.NET took a back-to-the-future approach with Windows Forms applications. XCOPY deployment, where the EXE and DLL files were simply copied onto disk and run, was billed as a major improvement. XCOPY fell short in many areas—who created the shortcuts in the Start menu, where do per-user settings go, and how does a new version of the application get installed?
An alternative to XCOPY was trickle-down deployment, where the use of the Assembly.LoadFrom() method bought assemblies down across the network or Internet. The trickle-down application had a bootstrap application that was installed via XCOPY or a traditional installer, and then the real application was pulled down on demand in a similar way to the Web deployment model. Trickle-down deployment was a good start but had a number of shortfalls. Code Access Security (CAS) was a problem—if the application did things such as use interop, the user’s machine needed to be permanently connected to the server that hosted the trickle-down assemblies. Retrofitting trickle-down to an application that was implemented without it was a huge undertaking.
Various third-party and product team solutions offered various aspects of the traditional install, XCOPY, and trickle-down models. The Updater Application Block produced by the Windows Forms team and Patterns and Practices group at Microsoft was one of the more successful attempts, and this has formed the foundation of ClickOnce.
ClickOnce is a deployment technique that has direct .NET Framework and Visual Studio support. You can deploy a project with ClickOnce by right-clicking the project node in the Visual Studio Solution Explorer and selecting Publish. The first page in the wizard allows you to select the publication location, as shown in Figure 37-3.
The next step is to determine the mode of application usage. You can install an application in online mode, which means it can be run only from the location it was published to and no Start menu shortcuts will be installed. Online-only mode is a lightweight model and is best for an application that a user will need to start only a couple of times. The other application mode is online/offline. In this mode, the install is more like a traditional application install, with Start menu and Add/Remove Program entries added. Because DiskDiff fits into the mode of a more traditional application, the online/offline usage model makes the most sense.
Once you’ve completed the Publish Wizard, you can deploy the application to the nominated publication location. End users will typically be notified of the application’s location by e-mail or a Web page, and then they can navigate to the application via a URL. If the application is an online-only application, and the permissions needed to run the application are granted to the zone that the application is installed from, the application will simply execute when the user clicks the hyperlink. If the prerequisites required to run the application (such as the .NET Framework) aren’t installed, the user will be prompted to install these first.
For online/offline applications, an installation wizard will guide the user through the installation process. For DiskDiff, using interop exceeds the permission set that would be granted to an application that originates from an intranet or Internet, and the end user is asked if they want to increase the permissions granted to the application. Figure 37-4 shows the warnings you’ll see for a DiskDiff installation.
One of the key benefits of deploying via ClickOnce is that you can update applications without having to check for or download updates. Online-only applications will always be up- to-date, as the end user is effectively running the application directly off the remote server. (However, a local cached copy will be maintained in much the same way that Web pages can be cached.) For online/offline applications, an application settings file called a manifest, which is produced when an application is published, will control when and how often checks are made for newer versions of the application.
ClickOnce in Perspective
ClickOnce solves many of the problems traditionally associated with desktop applications. By combining the ease and updatability of Web deployment with the richness of a traditional application, Windows Forms aims to provide the optimum client tier for a wide range of scenarios.
ClickOnce doesn’t make other deployment techniques such as XCOPY and MSI-based deployments redundant. XCOPY is still the simplest deployment options, and ClickOnce doesn’t offer the wide range of functionality that traditional installer technology offers. If a deployment needs to make significant changes to a system, such as installing a device driver or updating an operating system feature, you’ll still need a traditional installer. Windows is moving toward the managed code model in its Longhorn release, so this will reduce the need for MSI-based technologies.
Source: Gunnerson Eric, Wienholt Nick (2005), A Programmer’s Introduction to C# 2.0, Apress; 3rd edition.