In order to make a decision about whether or not to trust an application, it is necessary to absolutely identify its origin; that is, who deployed it. To this end, ClickOnce requires that both the deployment and application manifests be signed with an Authenticode certificate that identifies its publisher. An important aside: ClickOnce does not
require that the application's assemblies or other files be signed.
The identity baked into the certificate is used in several ways by the ClickOnce runtime. The publisher's name, for example, will appear in the ClickOnce trust elevation dialog boxes described above. In the case that the end-user is responsible for making the trust decision, this allows him to make the determination, "Hey, I can be sure
this application came from Microsoft, so I know
I can trust it."
ClickOnce taps into support in Microsoft Windows for the publisher whitelist and blacklist. This allows an administrator to control trust decisions for ClickOnce applications through policy. Applications whose manifests have been signed with a certificate in the Trusted Publisher list will be implicitly trusted. That is, the application will be granted the permissions it requests and the user will not be prompted at install time. Similarly, applications whose manifests are signed with a certificate in the Untrusted Publisher list will be blocked from installing. Administrators can place certificates in these stores using existing mechanisms, such as Active Directory.
The signature also allows the ClickOnce runtime to only accept updates to an application from its original publisher. This prevents an attacker from propagating malicious updates to all client machines by hacking the update server and posting his own binaries.
As with publishing and security, there is a property page in the Project Designer in Visual Studio 2005 devoted to signing. There you can set the certificate with which to sign the manifests at publish time. In the case that you do not have a bona fide certificate, the page allows you to create a temporary certificate, which will allow you to create manifests that are accepted by ClickOnce. However, to have the publisher identity show up on the Trust elevation dialogs and to take advantage of the white and black list, the certificate used to sign the manifests must be valid; that is, it must chain to a certificate in the Trusted Root certificate store and it must not be revoked or have expired.
Mage also supports signing ClickOnce manifests, as may later releases of Signtool, which is an all-purpose signing utility available in the Windows Platform SDK. This is particularly relevant to IT administrators who may need to re-sign the manifest after modifying the deployment properties therein.
I've mentioned that ClickOnce has a dependency on the .NET Framework 2.0, which usually prompts the question: as an application publisher, how do I ensure that the Framework is installed on the end-user's machine? If you're deploying to a managed desktop environment, then it will likely fall to the IT department to push out the runtime. But if you're in a position where you can't be sure whether the .NET Framework 2.0 is installed on the target machine, then you want the Bootstrapper. The Bootstrapper is a feature available in Visual Studio 2005 and the .NET Framework 2.0 SDK. It provides developers a way to fold the installers for their application and application prerequisites into a single integrated setup experience for the end-user. Configured from the Prerequisites dialog box on the Publish page (see Figure 9
), the Bootstrapper is built automatically by Visual Studio when you publish.
|Figure 9: At publish time, Visual Studio creates a bootstrapper that installs the prerequisites selected in the Prerequisites dialog box.|
When executed by the end-user, the Bootstrapper will detect whether or not the .NET Framework 2.0 is present on the user's machine. If it's not installed, the Bootstrapper will display a EULA and download and install the redistributable, while displaying progress UI. The Bootstrapper will also install the correct version of Windows Installer if it's missing because the .NET Framework 2.0 has a dependency on this Windows component. Once the Framework has successfully installed, the Bootstrapper will kick off the installation of your ClickOnce application. To your end users, however, it appears as if they've run a single setup.
The Bootstrapper is completely pluggable, so it can be configured to install pretty much any redistributable. Besides the .NET Framework 2.0, Visual Studio 2005 includes in the box the ability to bootstrap SQL Server Express 1.0, MDAC 2.81, and several others. Using the Bootstrapper, you can string these redistributables together into a single setup experience for your end-user. You can even plug in additional custom prerequisite installers yourself. The process required to do so is beyond the scope of this article; however, information is available on MSDN on how to do this.
There are instances of advanced deployment scenarios that go above and beyond what is natively supported by the ClickOnce runtime. Fortunately, there are APIs in the System.Deployment namespace in the .NET Framework 2.0 that should get you where you want to go. These APIs provide you mechanisms to manually control when your application checks and applies updates. The APIs also allow you to download optional application files dynamically after the initial installation.
Installing an application in a piecemeal way as portions of the application are required by the user is a great optimization to minimize the size of the application that comes down the wire at the initial installation point. The optional module may be an obscure component that is rarely required, or it may be fat content files that are not necessary to the user until they're specifically requested, such as Help documents.
|Figure 10: The Application Files dialog box lists the files described in the application manifest.|
By writing a little bit of code, you can support this scenario in your ClickOnce application. The code shown in Listing 1
brings down the file download group named Helpfiles
after the user clicks on the Help button on a form. Note that I am downloading asynchronously so I can avoid freezing the UI of the application.
To specify a download group for a set of files, you must go the Application Files dialog box, shown in Figure 10
, on the Publish tab. Under the Download Group heading, you can create a new group name in the dropdown for a particular file. Set this download group for any other file you want to download at the same time. When you publish your application, these files will be marked as optional and will not be downloaded onto the client machine until you expressly do so in code, as shown in Listing 1
In the code snippet below, I have added the code to hook up a progress bar on my form to give the user feedback that some action is being taken on his behalf.
Private Sub ProgressChanged(ByVal sender As _
Object, ByVal e As _
DeploymentProgressChangedEventArgs) Handles _
Me.DownloadProgressBar.Value = _
Armed with the .NET Framework 2.0 and Visual Studio 2005 (which shipped on November 7, 2005), you'll be set to write the client application you've always wanted to and let ClickOnce take care of the deployment and servicing of your killer app.