My Raid Into ClickOnce Land
What Is ClickOnce
ClickOnce is a Microsoft technology for automatic deployment of client applications. It is at least 2 years old, but I finally found time to look at it a little bit more closely. This article summarizes my experiences and thoughts about ClickOnce.
In a nutshell, ClickOnce is a lightweight installer built into the .NET framework 2.0. It expects applications to be published in a certain format on an HTTP server or in a file folder. It can
- Download application files from the server
- Warn user if the application requires elevated permissions
- Check for updates before each application run (optional)
- Add application icon in the startup menu (optional)
- Add the application to the list of installed programs in Control Panel
Applications are downloaded into a directory within the user profile. If multiple users wish to use the application, each of them should get their own copy.
Advantages of ClickOnce
Ease of Use
One of the most beautiful features of ClickOnce is that you don't need to
write a single line of the installer code. Visual Studio contains a very
convenient "publish" page that takes care of most of the deployment
headaches. To access the
Publish page right-click on your project in
Solution Explorer, choose
Properties from the menu and select Publish tab.
This option is available only for executable .NET projects (not for DLLs).
I was able to write and deploy my first "Hello World" style ClickOnce application in about an hour. There are no installation APIs or script languages to learn, and the publishing page is very straightforward.
When deployed on the client machine, ClickOnce applications are
normally run in a security sandbox.
of project properties allows to:
- Automatically calculate minimum security permissions required for the application (albeit this calculator does not always work correctly).
- Edit security permissions
- Apply sandbox security permissions to the debugger session
The last option is especially improtant, since it allows to uncover security violation errors on the developer machine, rather than on the client site after deployment.
Robust Client-Side Launcher
ClickOnce applications may optionally install a start menu shortcut. This shortcut does not start the application directly. Instead, it starts an application launcher process that (optionally) checks for the new versions and then starts the application proper.
One good thing about the client side launcher is that it does not die even if the update server is not available. It relatively quickly continues to launch the application as usual.
When developer publishes a ClickOnce application, it may mark new version as mandatory or optional upgrade. If client-side application launcher detects an optional upgrade, it asks user whether he wants to upgrade to the new version or not. The user may chose to skip the upgrade and continue to use the old version. If the upgrade is mandatory, the application launcher will update the application without asking the user.
According to Microsoft, client-side application launcher supports partial updates. Only those files that were actually modified since last version will be downloaded to the client.
Multiple Update Options
It is possible to configure application launcher to check for updates on every application start, periodically (e.g. every week), or not at all. Application itself can check for updates programmatically using ClickOnce API, but this requires coding.
Add/Remove Programs Support
When a ClickOnce application is installed, it is automatically added to the list of install programs in Control Panel. User can remove the application at any time by opening the Add/Remove programs screen and choosing "Remove".
Choice of Installation Media
You can install applications from the
- Internet/Intranet via browser
- Network share
The browser option serves the widest audience. You can use any web server (I tried Apache), but client browser must be IE. The installation does not work with Firefox. Microsoft promised to remove this limitation in .NET 3.0, but I did not test it yet.
Network share option might be good for certain scenarios in corporate environments. From the other hand, it may be simply to just put the software on the network share.
I don't see why would you use a CD-ROM option. If you went to the trouble of distributing CD-ROMs, you might as well put a real installer there. This is what people expect when they install programs from a CD-ROM.
What Is It Good For
ClickOnce is good for quickly deploying relatively simple self-contained applications to a uniform user audience. For example, it may be good for deploying a simple front-end application to corporate users.
Limitations of ClickOnce
Limited Behavior of Installer
Since the installer is supplied by the framework, customization options are very limited. Your application has to use the default installer supplied by the framework. All it can do is to create some files, and (optionally) a startup menu shortcut. Since there is no guarantee that the user will have administrative rights during the installation, all operations that require administrative access (installing to the GAC, registering COM components, etc.) are off-limits.
Also, it is not possible to customize the installation based on user input, operating system version, hardware configuration, etc. ClickOnce installer is strictly an "all or nothing" deal.
ClickOnce requiers .NET 2.0 and supports only .NET 2.0 applications. Other executable files (including native code) may be installed as well, but the entry point must be in a .NET 2.0 assembly.
There is no fine grained control over who gets the application. Anyone who has access to the application files on the web server can install the latest version of the application.
It is possible to uninstall the application, but since the uninstaller is not application-specific it will not remove any "traces" the application may have left on the system: files, registry entries, etc.
Limited Security Notifications
The installer will notify the user if an application attempts to get elevated permissions. However, it does not tell what exactly these permissions are. Even the "more info" dialog makes distinction only between full trust and partial trust permissions, but does not give details on exact permissions the application requests.
Limited Updater UI
When a new version of the application is detected, updater UI does not display its number to the user. Also, if the user chooses to skip an optional upgrade, they don;t have an easy way to come back and change their mind.
Limited Administration and Reporting Options
There is no (or I did not find an) easy way to determine current version of a ClickOnce application installed on the client. It is also not possible to get a list of all ClickOnce applications. Add/Remove programs dialog may offer some indiciation though. Unlike normal applications, ClickOnce applications don't have any value in the Size column. I does not look like the server can remotely determine what version of the application client(s) have.
Applications Must Be Self-Contained
ClickOnce applications must be self-contained since they "don't talk" to each other. This is good for security, but not so good for performance. If multiple users on the machine use the same application, each user will get his own copy. Also, if several applications use some common libraries, each application will have to download its own copy of the library. Certain GUI gadget libraries, such as Infragistics may reach several megabytes in size. This rarely causes a space problem, but it takes time to download all these megabytes over the network.
Limitations of The Publishing Environment
Security settings for the application are not always calculated correctly. There is no indication if the code has changed such that new security settings are required. Security settings must be recalculated manually
The publish process will blindly publish currently selected configuration, even if it is Debug, without asking any questions.
CickOnce or Windows Installer?
Microsoft article "Choosing Between ClickOnce and Windows Installer" suggests to use Windows Installer and not ClickOnce if your application needs to do at least one of the following:
- Install COM components.
- Register components for COM-Interop.
- Install services.
- Install to a specific location or to the Global Assembly Cache (GAC).
- Conditionally install components based on the operating system or runtime environment.
- Get user input at installation time.
- Configure system-level services such as Active Directory or COM+.
- Leave permanent "traces" in the system (files, registry entries, etc.) that will need to be removed upon uninstall.
ClickOnce is a low-cost instalation solution that has a number of significant limitations. You should carefully consider whether these limitations will affect your applicationa and your user base before choosing ClickOnce. From the other hand, if you don't mind the limitations, ClickOnce will significantly reduce your distribution pains. It may be quite good as an entry-level distribution solution for simple applications.