ClickOnce: Automated smart client deployment

In this article, Brian Noyes presents the options currently available for smart client deployment and how to choose among them. He then goes into detail about the new .NET 2.0 feature called ClickOnce for deploying smart client applications.

This tip offers a look behind ClickOnce, a significant deployment option for .NET Framework 2.0 smart client a


Smart client application architecture is gaining ground as a replacement for many intranet and some internet Web applications. Smart client architectures have many considerations that you need to take into account to build a well robust, reliable, scalable, performant, and secure app. However, building the application is only part of the battle. Once you get the smart client application designed and tested along with its supporting middle tier components, you need to deploy the application to client machines and support it with (possibly frequent) updates while it is there.

This article will discuss some of your options, including capabilities that exist with the .NET Framework 1.1, such as Windows Installer, No Touch Deployment, and the Updater Application Block, as well as those that will soon arrive with the release of the .NET Framework 2.0, specifically ClickOnce.

Design for Deployment

When you build smart client applications, you should be planning for deployment from early in the design. You have to decide what functionality is going to be exposed directly to the user, as well as which supporting components will reside on the client, and which will reside on the server. You have to choose a communications technology that the client will use to talk to the server, and you have to design in support for disconnected operations if appropriate for your application requirements. As a result of these design activities, you should be able to define what components will need to be deployed to the client machine, and what pre-requisites there are for the client machine to support those components.

Pre-requisites are things that you need to be present on the client machine just for your application installation to complete. If you are completing your installation with Windows Installer technology, you may have no pre-requisites because you could potentially include all of the pre-requisites as part of your installation. However, if you are using something like No-Touch Deployment or ClickOnce, there are much more restrictive bounds on what you can include as part of your deployment. I'll be talking in more details about each of these options later in the article. Examples of pre-requisites are things like the .NET Framework itself, MDAC, DirectX, Microsoft Office or other third-party component libraries.

You can minimize your deployment headaches by minimizing the footprint and complexity of the components that are deployed to the client. If your smart client application requires you to run ten different installers, set a bunch of registry settings, modify client environment properties, and do other things that could have serious impacts on other applications on the machine, you might want to rethink your design. With smart client applications, you want to avoid levying heavy requirements on the client machine just to be able to run your application. However, one of the other benefits of smart client applications is that they can better leverage the power of the client machine than a browser-based application. So even though you will want to minimize the number and complexity of pre-requisites, that doesn't mean you have to minimize the number or complexity of client side components that you deploy as part of your application.

Getting It Out The Door

Step one in planning for the deployment of your application is selecting the deployment technology that you will use. Your primary choices today include xcopy deployment, Windows Installer technology, No Touch Deployment, and the Updater Application Block. There are also a number of powerful and interesting third-party deployment products that provide both push- and pull-models for deploying client applications. A push model is one where you can push the applications out to the client desktop machines from a central location, and potentially manage and monitor those applications as well. A pull model is one where software on the client goes out and retrieves the application files from one or more locations when they are needed for deployment or update.

If your application needs are simple, the number of desktops you need to deploy to is small, and you have networked access to those machines, one of the easiest approaches to use for deployment of .NET Framework applications is to use xcopy deployment. Simply stated, xcopy deployment means you use any file transfer mechanism at your disposal (including the DOS xcopy command, FTP, or file transfer utilities) to copy the application files into a target folder on the client machine where they will run. If your application has been designed with this deployment model in mind, you should then be ready to run and could push out your applications and updates manually or through simple script files. You can implement either push or pull techniques through xcopy deployment.

High-Impact Client Deployment

Windows Installer is the primary model for deploying complex desktop applications today. It is a service of the Windows operating system with an associated API and specifications for creating deployment packages (.msi files). Deployment packages can be created using Visual Studio Setup and Deployment projects, or you could use a number of third-party installer products like InstallShield, Wise Installer, or ZeroG InstallAnywhere.

With Visual Studio Setup projects, you configure file system, registry, user interface, file types, custom actions, and launch conditions through a set of views in the project (see Figure 1 below). Although the built-in capabilities of the installers you can create through setup projects may feel a little limiting, you can ultimately get your installer to do anything you need it to do because you can run custom installation steps that can be defined in script files, external executables, or, better yet, custom .NET installer classes. The output when you build your Visual Studio setup project is a Windows Installer .msi file and accompanying setup.exe that you can then use to deploy your entire application. You can add in other merge modules, which are installers that are designed to be integrated into other installations, allowing you to add pre-requisites to your installation and deploy just one package.

Figure 1

Through the capabilities of Windows Installer technology, you can support deployment of arbitrarily complex applications to user desktop machines. The problem with using Windows Installer is that an administrator has to run the installer package on each and every desktop machine where you expect the application to run. For small organizations with fairly static applications, that may not be a huge burden. But for very large organizations or if your application requires frequent updates, the requirement for an administrator to run the installation on every machine quickly becomes unmanageable. As a result, various alternatives have emerged to allow more automatic deployment and update of smart client applications.

Low-Impact Client Deployments with No-Touch Deployment

No-touch deployment is a capability that was introduced with the .NET Framework 1.0 to allow end users to automatically download and execute WinForms applications over a network. No-touch deployment is also called zero-touch, href-exe, auto-deployment, and a number of other monikers. No-touch deployment has not gained widespread use, partly due to a lot of people not even knowing about the capability, and partly due to some limitations of the technology. No-touch deployment requires that the client machine already have the .NET Framework and Internet Explorer installed.

The way no-touch deployment works is that you first place your WinForms application executable and its dependencies into an application folder on a Web server. You then provide a link or URL to the executable file to users. When the user clicks on the link or addresses the URL in a browser, the .NET runtime and Internet Explorer on the client machine will detect that the executable that is being downloaded is a .NET executable. As a result, the user will not be prompted to open or save the executable as they normally would be for an unmanaged executable. Instead, the application will be downloaded and cached in the Internet Temp Files cache under the user's profile, and the application will then be launched on the user's desktop (see Figure 2). The next time the user clicks on the link for the same application, the browser will check to see if there is a newer version on the server (based on its file date/time), and if so will download that version and launch it. But if the currently cached version is up to date, it will just be launched from the local cache instead.

Figure 2

The application will run with Code Access Security (CAS) permissions based on the URL from which it was launched, so by default it will be prevented from doing any operations or accessing any resources that could be harmful to the user's machine. However, those same default protections will also keep a no-touch deployed application from doing anything really meaningful (such as accessing a database, Web service, or the user's file system) unless you provide a workaround.

The best workaround is fairly straightforward -- sign your assemblies with your organization's strong name, and configure a custom code group on client machines to give your strong name either full trust or appropriate levels of trust for the kinds of permissions your applications need. Once you have configured a code group on the user's machine with the membership condition set to your strong name's public key token (see Adding CodeGroups in MSDN Library), any applications that are launched on that machine will be granted the privileges specified in your custom code group. This will be true regardless of the location that they are launched from based on the combination of the default .NET CAS policies and the addition of your custom code group.

The other downside to no-touch deployment is related to the way that .NET Framework applications load assemblies on which they depend. .NET assemblies are loaded on demand the first time that an object is created or a call is made into code within that assembly. This is a good thing for most applications because it minimizes the start up time by not loading everything at once. Assembly load at runtime for local applications is relatively fast, and so the user will rarely even know when a new assembly is being loaded up based on user interaction accessing code in an assembly that has not been loaded yet.

However, for no-touch deployed applications, the loading of an assembly includes downloading that assembly from the deployment server, which could take a while depending on the size of the assembly and speed of the connection. As a result, if you make a call into an assembly for the first time based on user interaction, such as a menu selection, the user may see a significant delay while the newly accessed assembly is downloaded, cached, and loaded on the user's machine. While this is going on, the application will appear to have hung, and user's may get frustrated and kill the application.

There are several workarounds for the download and load delays of assemblies using no-touch. The first is to pre-load the assemblies during launch by making a call (possibly to a dummy method) within each assembly that the application needs. This will trigger a download if needed, but may significantly increase the launch time of your application. If you are going to do this, a common thing to do is to show a splash screen while your application is launching with some progress indication so that the user will be patient while the download occurs. Alternatively, you could give some busy and downloading indication to the user in each method that might end up being a first call into a different assembly, but that might be more disorienting if there are numerous paths a user might take to call an assembly for the first time.

There are a number of other challenges in implementing no-touch deployment that you may have to tackle to use no-touch deployment effectively. To use a no-touch deployed application, you must be online and able to communicate with the deployment server from whence your application was originally deployed, and there is really no workaround for this. Additionally, getting a config file or other application dependencies downloaded can be problematic because the Web server you are using for deployment might want to block those files by default. If you have custom installation steps, you can always accomplish them using custom code that runs the first time your application runs, provided your application assemblies and the user have sufficient permissions to do whatever those operations involve.

If you would like more information on no-touch deployment, then I would suggest Windows Forms Programming in C# by Chris Sells (Addison Wesley, 2004) which dedicates an entire chapter to web deployment of WinForms applications.

If you plan to use a Windows Installer approach but want to have the benefit of automatic updates in your application, there are two choices you should take a look. The App Updater component is available from the GotDotNet workspaces is a simple to use component for retrieving updates to your deployed application from a central deployment server. The Updater Application Block is a more comprehensive implementation of application updating that allows custom pre- and post-installation steps, pluggable downloaders, and lots of other features. As a result, the Updater Application Block will remain relevant for some time to come, even when the .NET Framework 2.0 and ClickOnce are available. Check out two Bill Wagner articles -- Using the Updater Application Block and Update Desktops Automatically Using the App Updater Component -- for more information on those capabilities.

The Wave of the Future -- ClickOnce

A key new technology for smart client deployment is ClickOnce, which will be part of the .NET Framework 2.0. ClickOnce provides a trustworthy mechanism for automatically deploying and updating Windows applications from a centralized deployment location. The way ClickOnce works is as follows.

You design and build your Windows client application using .NET 2.0. Your client application may include the ability to communicate with middle tier or database server using a variety of protocols in a distributed network that may span a LAN,a WAN or the open Internet. Your application might also include capabilities designed to be used when the user is not connected to the network, such as if they are working on a laptop while traveling.

Once you have tested the application and you are ready to deploy it to end-users, you publish the application to a deployment server. You then provide a link to end-users that they can use to launch your application the first time. When the user clicks on the link, the application is downloaded to the user's machine, is cached, and is launched in a secure sandbox provided by CAS. Depending on the update settings for the application, the next time the user launches the application, the .NET runtime will check the deployment server to see if there are any updates available, and if so, it will download and use those updates.

Even with such a simple concept, the story is a lot more complicated because of the number of options that were designed into ClickOnce to give you a lot more control and flexibility in designing your deployment. ClickOnce supports two deployment models. The first is that you can configure your application so that it is only available online. When you select this option, a ClickOnce application behaves a lot like a no-touch deployment application does today. The application can only be launched using the URL to the application manifest on the deployment server, and every time it is run the deployment server will be checked for updates. If any are available, they will be downloaded and the most recent version will run.

Even with this model, ClickOnce addresses all of the primary difficulties with no-touch deployment. The security is addressed through a configurable scheme that I will discuss shortly. The downloading of application components is controlled explicitly through the application manifest so that you can determine whether files are downloaded immediately or not until they are used. Finally, because the application files are identified through the manifest and downloaded by the runtime based on those entries, you don't get into some of the sticky situations you can with no-touch, such as with trying to get the config file for the application to download as well, or the fact that in no-touch deployment the most recent “version” is really just the one with the newest timestamp.

The other model for deployment with ClickOnce allows the application to be available offline as well as online. When you select this option, you get a bunch of choices on update behaviors that also become available. You can choose whether updates are checked for, whether they are optional or mandatory, whether they should be checked for before the application starts or in the background while it runs, and a number of other options. You can also take over and use the programmatic API associated with ClickOnce to do on-demand updates if needed (see Figure 3).

 private void OnUpdateApplication(object sender, EventArgs e) { ApplicationDeployment deployment = ApplicationDeployment.CurrentDeployment; if (deployment.CheckForUpdate()) { deployment.Update(); MessageBox.Show("Update downloaded, application" + "will now restart."); Application.Restart(); } else { MessageBox.Show("No updates available"); } }

Figure 3 : On-Demand Updates with the ClickOnce API

When you launch a ClickOnce application that supports offline use, it will download and cache the application file, create a Start menu shortcut for launching the application, and will add an Add/Remove Programs item to allow you to “uninstall” it.

ClickOnce Security

One of the key features of ClickOnce is the security models it supports. First and foremost, ClickOnce was designed to be a trustworthy deployment mechanism. Specifically, it was designed so that the installation of the application on the client machine cannot harm any other applications or data as part of the process of deployment, and that the default security measures on the client machine to prevent the code that is downloaded from performing any potentially harmful operations on the user's machine.

The first part of those measures is provided by the fact that ClickOnce installed applications are isolated in some obfuscated directories under the user's profile that are created by the runtime at the point when a given version is first launched (see Figure 4). Besides downloading, caching, and executing the application files from those obfuscated folders, a ClickOnce app can only make two other forms of modifications to a user's machine -- the automatic addition of a Start menu shortcut for launching the application based on the publisher information contained in the deployment manifest, and the addition of an Add/Remove Programs item in the control panel to allow the removal or rollback of a ClickOnce deployed application.

Figure 4

The runtime security aspect is a little more complex to describe and understand, because the permissions granted to a ClickOnce application are the result of a combination of factors. First, when a ClickOnce application is deployed, you specify the security permissions required by the application as part of the application manifest. When that application is launched, the .NET runtime will decide based on some configuration settings on the user's machine whether to support prompting the user to elevate the application's permissions to those specified in the application manifest.

An alternative and preferred way of doing it is to deploy a trusted publisher certificate to the client machines. You then sign the ClickOnce application manifests with that same certificate when you publish them. When a ClickOnce application that has been signed by a trusted publisher is launched, it will be automatically granted the permissions requested in the manifest without prompting the user, and an Application Trust will be created under the User security policy on the client machine granting those privileges.

Deploying an Application with ClickOnce

Just to make this more concrete, let's step through a fairly simple example. Say you designed a simple data entry application that performs direct data access against a SQL Server database. The data access application allows you to browse and view customer information, both in a grid and in a details form (see Figure 5). This application is included in the download code for you to play with. This sample was created with Visual Studio 2005 Beta 1 using the drag and drop data design features of WinForms.

Figure 5

You design, build and test this application on the local machine. Now you want to try out ClickOnce deploying it to client machines on a local area network. The first step is to open the project in Visual Studio 2005. You then go to the Build menu and select Publish <projectname>, where <projectname> is the name of the Windows Forms application that you are working with. This brings up the Publish Wizard that allows you to specify or review the key parameters of the ClickOnce deployment. The first step specifies the address of the deployment server to which you are publishing the application (see Figure 6). The next step allows you select whether the application will be available offline or only online (see Figure 7). The final step requires you to sign the manifests of the deployment using a strong name key file, which the wizard will generate for you if desired (see Figure 8). In Beta 2 of Visual Studio this last step will be changed to only allow you to sign your manifests using a publisher certificate rather than a strong name key file. Tools will be included to help you create your own publisher certificate if needed.

Figure 6 : Publish Wizard Step 1

Figure 7 : Publish Wizard Step 2

Figure 8 : Publish Wizard Step 3

Once you click Finish in the wizard, the project is rebuilt to make sure it is up to date, and then the application and all of its dependencies is published (copied) to the deployment server and is placed under a set of folders there that provide separation by application and by publishing version.

Visual Studio then launches a browser and loads a test page containing a link allowing you to test out the ClickOnce deployment from the local machine by clicking on the link in the same way that a real user would deploy the application the first time through a link. When you do this with the default project properties for a ClickOnce deployment, the user will be prompted that an application is being installed and requires increased security privilege to run. This is because the default security policy that is specified for a ClickOnce application in Beta 1 is for Full Trust. If the user clicks the Install button in the prompting dialog, then the application will be granted full trust on that machine automatically. Likewise, if the publisher certificate that the application is signed with is configured on the client machine as a trusted publisher, then the user will not be prompted and the permissions will be granted silently. The trusted publishers functionality is not working yet in Beta 1, so we will have to wait patiently for Beta 2 in order to play with those features.

You can configure the specific security permissions required by an application through the Security tab of the project properties editors in Visual Studio 2005, and you can access all the fine grained options of ClickOnce deployment and update behavior through the Publish tab of the project properties (see Figure 9).

Figure 9


There are a lot of options available for getting client applications put onto user's desktops. For smart client applications, you will want to try to design your application in a way that allows you to use as lightweight and automatic of a deployment mechanism as possible. Today you can use no-touch deployment and/or the Updater Application Block to have a lightweight, automatic deployment and update mechanism. As soon as you can count on being able to install the .NET Framework 2.0 on your target client machines, you can start using ClickOnce. Now and in the future, if you need to perform high-impact installs on the client, Windows Installer technology will be the way to go.

Download Source Code


Brian Noyes is a Microsoft Regional Director and MVP, and an international speaker, trainer, writer and consultant with IDesign Inc. He speaks at Microsoft TechEd US, Europe and Malaysia, Visual Studio Connections, SDC Netherlands, DevTeach Montreal, VSLive!, DevEssentials and other conferences, and is a top rated speaker on the INETA Speakers Bureau. He has published numerous articles on .NET development for TheServerSide.NET, MSDN Magazine, MSDN Online, CoDe Magazine, Visual Studio Magazine, asp.netPRO, .NET Developer's Journal, and other publications. Noyes' latest book, Data Binding with Windows Forms 2.0, part of the Addison-Wesley .NET Development Series, hit the shelves in January 2006, and will be followed this summer by Smart Client Deployment with ClickOnce.

This was first published in January 2008

Dig deeper on Smart client application development best practices



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: