This article explains the definition of ClickOnce applications. This is a Microsoft .Net Framework deployment method in which the user can easily install an application with the click of a URL or *.application file from a shared folder or media.

Description

The principal reason for this type of deployment is the ease of installation for the Windows user. Administrators can easily deploy installations or updates for this type of installer. ClickOnce applications also eliminate the need for administrator access for the installations.

Administrators see two types of xml files executable on the ClickOnce installer’s environment, a *.exe.manifest, and *.application. This type of installation can be made by a URL, a network share or even a portable media. No administrator access is required for this type of installation.

The application can be fully installed on the client machine like any other software, or run in cache mode in which only part of the software is installed. In cache mode, the user needs access to the location of the central software. This second method resolves the issue of the consumption of hard drive space on the user’s machine. The big difference compared to other more common installer types is that ClickOnce applications are installed in <USER PROFILE>\LocalSettings\Apps. This is the main reason why a lot of issues appear when administrators try to run these types of applications inside terminal sessions.

From a security perspective, ClickOnce applications use internal certificates to verify authenticity of the publisher of the application. This method prevents the harmful problem of an application’s publisher portraying itself as legitimate.

ClickOnce deployment is only supported with .NET Framework 3.5 with Internet Explorer as the only supported browser, but with .NET Framework 3.5 SP1 new extensions were included in which the user can use other third party internet browsers. Microsoft article KB2020945 states that ClickOnce cannot be used to deploy applications on any Windows Terminal Servers including 2003, 2003 R2, 2008, and 2008 R2.

Types of Files

ClickOnce is controlled by 2 (two) xml manifest types of files: the manifest (*.exe.manifest) file and the application file (*.application).

The application file is the deployment that manifest in with the deployment method that is defined. This includes version checks, update behavior, and identity along with digital signature, if required.

The manifest file describes the application, assemblies, dependent libraries, and permission required by the application. To execute the installation of the application, the user clicks the “*.application” file, not the “*.exe.manifest” file.

Requirements

The minimum requirements for a ClickOnce installation are the following:

Application Streaming or Publishing with Citrix XenApp

Citrix XenApp does not support this type of installation technology, but has some simple workarounds that an administrator can use for this type of application with XenApp.

By default, ClickOnce applications are not installed on the Program Files folder in Windows like other applications. Instead, they are installed on the profile folder of the User. This is the main reason why the user does not need administrator permission for the installation of these applications. Because of this, they cannot be published on a Citrix XenApp server.

Scenario 1 (Published ClickOnce through Internet Explorer)

The administrator from Temp Company publishes the Web address from the ClickOnce application. If the XenApp server is successfully configured to publish the URL, no errors are found during the procedure.

On the other end, a user logs on to this XenApp server to access the Web URL. After logging on to the client and double clicking the shortcut, the user receives a ClickOnce installation procedure. The first time the installer runs, the application installs on the user’s profile, and when opening a second session and accessing the application, the installer runs again. This happens because the session does not maintain the Local Setting folder of the user's profile. So, every time a user opens a terminal session, the ClickOnce system detects it as a new profile and runs the installation procedure.

Workaround for Scenario 1

The administrator should set up a folder redirection for the local setting folder of the user’s profile. This is the folder where ClickOnce applications install by default.

Another method is using the Roaming Profiles, which carries the user profile anywhere the user logs on, including Terminal Sessions.

Scenario 2 (Published ClickOnce Installed in a Server)

The administrator from Temp Company installs and publishes a Web ClickOnce application. If the XenApp server is successfully configured to publish the URL, no errors are found during the procedure.

When the users log on to the XenApp server to access the application, they receive permission errors or “file not found” errors when trying to open the application.

Workaround for Scenario 2

The administrator can locate the installed application on the server inside the administrator’s profile and copy the files to a more stable location, for example, the C:\ or C:\Program Files folder. Then, the administrator can publish the application from the new location. This method might not work on some applications, especially applications that are hard coded to work on a specific file path. Aggressive application testing must be done to verify the application before sending it to production.

Scenario 3 (Streamed ClickOnce Profile)

The Streaming Profiler tool is not compatible with the ClickOnce file extensions. The administrator can profile the ClickOnce application through a URL, but if the application is being installed in the default location inside the local setting folder of the user profile, issues might appear, similar to Scenario 1 above.

Workaround for Scenario 3

The administrator can locate the installed application on the server inside the administrator’s profile and copy the files to a more stable location, for example, the C:\ or C:\Program Files folder on the computer. From here, try to make a profile. Instead of running an installer, manually add the files and registry keys required. Because the application was installed before running the profiler, the registry keys and file extension association should be captured by the profiler. This method might not work on some applications, especially application that are hard coded to work on a specific file path. Aggressive application testing should be done to verify the application before sending it to production.

Scenario 4 (Screen Flickers)

When users try to access the application the screen flickers and they see a gray background instead of the application splash screen.

Workaround for Scenario 4

This is an identified issue with Windows Presentation Foundation (WPF) applications with Microsoft Terminal Services. Microsoft provides a hotfix for this issue in which the administrator should install on the server. The information regarding this issue is in the Microsoft article, KB955692.

Scenario 5 (Application Launch)

Even if the application is installed and published correctly, the application itself never launches.

Workaround for Scenario 5

Users identify an issue when the application uses ConfigStartupTrace.log file, which is located on C:\Temp. Because the location is prohibited by normal users, developers of the application should change the location of the log file on a location where user can have access.

Scenario 6 (Seamless Application Launch)

The application never launches when published as a seamless application.

Workaround for Scenario 6

The application may launch within a Published Desktop instead. Microsoft do not support deploying ClickOnce on any Windows Terminal Servers including 2003, 2003 R2, 2008, and 2008 R2 - see Microsoft KB2020945. ClickOnce apps are not supported as RemoteApps. If the application does not work as a Terminal Services RemoteApp it will likely not run as a seamless application either.

Conclusion

ClickOnce applications are unpredictable because of the way they install on a user machine. The workarounds given in this article might not work with all applications. The recommended method for publishing a ClickOnce application is to ask the application vendor for a Non-ClickOnce installer (for example, *.msi or *.exe) for the application, in which the application is installed in the normal location in Windows.