Beta 2 is the time in a release cycle when Microsoft traditionally finalizes the feature set of a product and assess which new features are going to make it into the final product. As stated in last month’s article, the Visual C++ IDE team has a much heavier workload than the IDE teams associated with the managed-code-only compilers. Consequently, not all the features that the CLR introduces and the other IDE teams implement will be available in C++ in the same timeframe.
For Whidbey release, the IDE team has spent a large amount of time making IntelliSense a reliable and high-performance part of the IDE. This focus on IntelliSense has necessitated cuts in other areas, and the Class Designer (covered in Part 2 of this series) and ClickOnce IDE support have been cut. Dealing with the lack of IDE support for ClickOnce is not a major issue (more on that shortly), but the removal of the Class Designer is a real shame for C++ developers who were looking forward to the introduction of a built-in modeling and documentation tool. A number of third-party offerings are available in this area, however. A future article will cover these.
The popularity of Web applications can be attributed to two key advantages that they over their non-browser-based competitors: the ability to offer the application to clients on any platform and the simplified deployment model. In many corporate scenarios, the cross-platform issue is not a major consideration because the group of machines that the application will be deployed on is tightly controlled. Still, deployment and update issues can outweigh the benefits offered by a traditional rich-client application. Microsoft has recognized that deployment and updates are a major issue for traditional applications, and has made significant efforts to allow .NET Windows Forms to share the distribution qualities that have made ASP.NET so successful.
These efforts have resulted in the Updater Application Block, available as part of the Microsoft Patterns and Practices Enterprise Library, which allows applications to automatically update themselves by pulling newer versions of their assemblies from a remote file share or Web server. In .NET 2.0, these concepts have been extended further with a new technology called ClickOnce. ClickOnce incorporates the concepts of Web applications, XCOPY deployment, and the Updater Application block to deliver a model for rich-client (or, to use Microsoft’s new term for traditional applications, “smart client”) deployment.
ClickOnce offers two modes of application installation: online only or full installation. For online-only applications, the application behaves much like a .NET application deployed through a HREF link today. The binary file is downloaded onto the local machine and stored in the Downloaded Program Files cache, but the user must be connected to the server that originally served the application for the application to run. In contrast, ClickOnce applications can be installed to run directly from a local drive. This installation mode resembles a traditional MSI install, with shortcuts added to the Windows Start menu and entries added to the Add or Remove Programs dialog.
To enable ClickOnce to work, a description of the files and assemblies that make up an application is required. In .NET 1.x, no real concept of an application exists. The dependencies of a particular assembly are recorded in its assembly manifest with no strong notion that a particular group of assemblies are part of a coherent group needed to execute an application. To address this need, .NET 2.0 and ClickOnce introduce the notion of an application manifest.
An application manifest is a standalone XML document that records the files and permissions that make up an application. The production of an application manifest is a development-time activity, and it is one of the tasks that IDE integration of ClickOnce made easier. Although IDE support would be nice, the .NET Framework SDK ships with the tools required to build this manifest file (even though given the file is XML, hardcore developers have the option of manually producing it). The next section covers how to use these tools.
The other file that is needed for a ClickOnce deployment is a deployment manifest. This file is more of a deployment-time task, and it would typically be created and updated by operations staff using the command-line or GUI tools in the .NET Framework SDK. A deployment manifest contains information about the most current version of an application available, the location of the application’s files and manifest, and the deployment mode and update policies. C# and Visual Basic .NET have IDE support for generating this file, but as with the application manifest, the file is relatively easy to produce with .NET Framework tools.
Deploying a C++/CLI Application Using ClickOnce
As a very simple example of deploying an application using ClickOnce, consider a C++/CLI Windows Forms application compiled with /clr:pure. This means that the application will use only MSIL instructions, but it may not be verifiably type safe (for those familiar with C#, it will be the equivalent of a C# application that uses unsafe features). To generate an application manifest file, the Manifest Generation and Editing Tool-Graphical Client (MageUI.exe), which ships as part of the .NET Framework SDK, can be used. This tool is a Windows Forms application that supports the creation, editing, and signing of both application manifests and deployment manifests.
The simplest way to launch MageUI is to start the Framework SDK command prompt (Start| All Programs | Microsoft .NET Framework SDK v2.0 | SDK Command Prompt) and simply type MageUI. On the first page of the tool, enter basic application information, as shown in Figure 1. In this case, the application is called COTest.exe.
Figure 1: Manifest Generation and Editing Tool-Graphical Client
The next step is to include a list of all the files that make up the application and locate the assembly that contains the application’s entry point. MageUI can do this automatically if all the files are placed in a single directory. This simple demo requires only a single file. Figure 2 shows the File page of MageUI.
Figure 2: Selecting the Files and Entry Point for an Application