How to: ClickOnce Deploy
So you've finished developing your feature-rich, light-speed smart client application, and now you want to deploy it to using ClickOnce. What do you have to do?
You first need to configure and generate the ClickOnce manifests. You'll be happy to know that all versions of Visual Studio 2005, including the Express editions, have full support for ClickOnce. Visual Studio will not only build the application and create the manifests for the deployment in a process referred to as publishing, but also copy your application files and manifests to the location of your choice.
|Figure 2: Visual Studio 2005 includes a project designer page dedicated to ClickOnce publishing.|
ClickOnce is integrated into the new project designer in Visual Studio. You can access this designer by right-clicking your project in the Solution Explorer and selecting Properties. You will notice that there is a Publish tab in the designer, as in Figure 2
On this page, right off the bat, you'll want to indicate whether the application is installed in online or offline mode. The decision you need to make is whether you want your application to operate as a Web application, or whether you want the user to be able to activate the application when he is offline.
Next, you want to indicate what files are actually in your application. You'll notice on the Publish tab, there is an Application Files button, which (when clicked) brings up a list of application files that will make up your deployment. These are the files that will be listed in your application manifest and that the ClickOnce runtime will download on the client's machine. By default, your application's executable is shown in the list, along with any other assemblies and files in your project. Assemblies upon which your application has a dependency will also appear.
To add to this list of files, you need to add the file to your project through the File menu or Solution Explorer context menu. After adding a file in this way, go to the Application Files dialog box, find the file that was added, and ensure that the publish status column is set to Include.
By setting a dependent assembly's publish status to Prerequisite in the Application Files dialog box, you can get the ClickOnce runtime to not bundle this file with your application, but instead have it look for the assembly in the Global Assembly Cache or Windows Side-by-Side folder on the target machine when the application is installed. If ClickOnce cannot find the file in either of these locations, then it will stop the installation and display a dialog box indicating that the file could not be found. Files marked as a Prerequisite will not be updated with the application. By default, the .NET Framework 2.0 is listed as a prerequisite for your application in the application manifest, although it is not listed as an entry in this dialog box.
|ClickOnce supports client application install from Web server, UNC share, and CD.|
Now you're ready to set the Publish Location-the place where the application files and manifests will be published to. Visual Studio 2005 supports publishing to Web server, UNC share, FTP server, and local path.
You're almost thereyou just need to indicate the install location. This is the location where your application deployment will be hosted, and where users will install the application from. If the install location is the same as the publish location, filling out this field is optional.
Now you're all set to publish. You can click the Publish Now button on the Publish tab in the project designer. Alternatively, there's a publish wizard that walks you through the steps of setting these properties. This wizard is accessible on the Publish tab, or by right-clicking the project in the Solution Explorer and selecting the Publish option in the context menu.
While it may seem like I'm plugging Visual Studio, it turns out that it is not the only way to create a ClickOnce deployment. There is a tool in the .NET Framework 2.0 SDK called Mage, which offers a stripped down way to access the manifest properties as you would in Visual Studio. The tool offers a UI-based experience, which is handy for administrators tweaking manifest properties. It also runs as a command line utility, which is convenient for build lab scenarios.
Another tool in the SDK that supports ClickOnce manifest generation is MSBuild. You can employ the MSBuild tasks used by Visual Studio as part of its publishing operation to support your automated build lab scenarios.
After the initial release of the application, you may be on the hook for servicing, or there may be additional features that users are clamoring for. While it's great to have this job security, you want to get these updates out to the users in a quick and cost-effective way.
Fortunately, ClickOnce offers a simple deployment and install experience for updates. Similar to the initial deployment, you post your updates to a central update location, which likely will be the same place to which you initially deployed the application. The ClickOnce runtime on the client machines will automatically apply the updates as they're made available.
Let's dive into the details of ClickOnce updating on the client side. If the application is an online application, then the user always gets the latest bits because he activates the application directly from the server or UNC-just like a Web application!
|Figure 3: Configuring the update semantics of your ClickOnce application can be done in the Updates dialog box.|
If the application is installed in Offline mode, then the ClickOnce runtime on the client machine will automatically poll the server for updates. When it detects that an update is available, ClickOnce downloads the change. ClickOnce supports two native update semantics for offline applications. The first option is for the runtime to check for updates prior to the application starting. This setting allows you to be sure that the latest version of the application is always run. The other option is to check for updates after the application starts. This means the next time the application runs, it will be the updated version. This option allows you to avoid slowing down the activation of the application.
With all this talk of downloading, there can be a legitimate concern that this will place an undue tax on bandwidth. Fortunately for both the online and offline application, only the application files that have changed in the update, based on a hash, are downloaded into the user's app store.
In Visual Studio 2005, configuring your application update semantics and issuing updates are easy. To set the update behavior for you application, use the Updates dialog box (see Figure 3) on the Publish tab. There you can set whether the application will check for updates automatically, and whether it should do so before or after starting. If the application checks for updates after activation, you can set the period between updates (e.g. every 3 days). You should note that neither of these settings constitutes a true background update.
You can also use the Updates dialog box in Figure 3 to set the update URL field. This information is baked into the deployment manifest because the ClickOnce runtime uses it to know where to check for updates. If your users are installing from UNC or URL, this will likely be the same as your installation location. If that's the case, there's no need to set this property as your install location is taken by default.
Sometimes the installation and update location fields will differ. For example, some users want to install from CD, then update from a server. This scenario is possible by setting your installation location to your CD. Then set the update URL in the Update dialog box to be your update server.
|Figure 4: Offline ClickOnce applications can be uninstalled and rolled back from the Add and Remove Programs list.|
To issue an update is remarkably simple in Visual Studio 2005. After you have made the changes that constitute the update to your application, you simply re-publish your application to the update location. The ClickOnce runtime on the client machines will detect the change and update the application accordingly.
Remember how I mentioned that for ClickOnce applications installed as offline, an entry is added to the Add and Remove Programs? In addition to letting the user uninstall the application, it also allows the user to roll back to previous versions of the application. ClickOnce retains one version back of the application for the user to revert to in this way, as shown in Figure 4
The other way to roll back is on the server. Let's say that you issue an update but discover to your horror there's an embarrassing bug in the new version. You want all users to revert to the previous stable version of the product until you fix the issue. To do this, you use Mage to update the deployment manifest on the server to point to the desired version of the application manifest. When the ClickOnce runtime on the client machine next checks for updates on the server, the application will be reverted to this previous version.