Optional and Required Updates
|Figure 5: Users have the ability to defer optional updates to a ClickOnce application. This dialog will not appear when an update is required.|
For offline applications, there are two types of updates: optional and required. When ClickOnce detects an optional update on the server, the user is presented with a dialog box, as in Figure 5
. The user can either accept or skip the update.
If an update is set to be required, then it means the user is not given the option of deferring the update. In addition to no dialog being shown, the Add and Remove Programs entry for the application prevents the user from rolling back to the previous version of the application.
To make an update required in Visual Studio 2005, you need to set the Minimum Required Version field in the Updates dialog box to match the version of the application you're currently publishing. You can find this version value on the main Publish tab. At install-time of the update, the ClickOnce runtime will compare the minimum required version to what the user currently has. If the client has a lower numbered version, then ClickOnce will force the user to update.
|Figure 6: Among other things, your ClickOnce deployment can be localized from the Publish Options dialog box.|
Let's suppose you've localized your application in French, and you now want to publish the satellite assemblies and resources in Visual Studio 2005. To do this, you need to select Options on the Publish tab, as in Figure 6
, and in the dropdown for Publish Language, select French
If you open the Application Files dialog box, you'll notice that the French satellite assemblies are now included by default. When you publish, these localized resources will be carried along with your application.
At install time on a target machine, ClickOnce will show the UI in French, provided the matching French language pack of the .NET Framework 2.0 is installed on the user's machine. In any case, the French satellite assemblies will come down when the application is installed, and bingoyou have a localized application running on the end-user's machine.
ClickOnce Security Model
ClickOnce and the Common Language Runtime (CLR) introduce a security model that operates over the entire application, as defined by the application manifest. Gone are the days of granting permissions to individual assemblies.
Deploying Unmanaged Components
|You can ClickOnce-deploy unmanaged components provided they are deployed privately. Even COM components can be deployed via ClickOnce using an OS mechanism referred to as Registration-Free COM, available on Windows XP and above.|
You can ClickOnce-deploy unmanaged components provided they are deployed privately. Even COM components can be deployed via ClickOnce using an OS mechanism referred to as Registration-Free COM, available on Windows XP and above. You can find out more here
By default, a ClickOnce-deployed application runs within a sandbox in that the application is granted a limited set of permissions that depend primarily on the security zone from which it is deployed. The security zones are Internet, Local Intranet, and Local Computer, where each zone allows a greater set of permissions by default. Internet is the most restrictive, and Local Computer imposes virtually no limit. If the application attempts to do something for which it does not have permission, the CLR will prevent the action and throw a security exception.
The set of permissions for the Internet and Local Intranet are quite restrictive. For example, your application will not be allowed to access the target machine's file system or touch the registry.
So how do you get permission to do these actions, while avoiding the pesky security exceptions? There are two aspects to this problem. First, as the developer, you need to figure out what set of permissions your application requires. Second, in the case that the application is demanding a set of permissions that exceeds the defaults for the security zone from which it is being deployed, the application must be granted elevated trust by either the user or an administrative entity responsible for this decision.
Visual Studio offers a number of tools to help you hone in on the set of permissions required by your application. Here is a quick summary of your war chest:
|Figure 7: The Security project designer page helps you determine the permission requirements of your ClickOnce application.|
- Debug-in-Zone (DIZ). In the Project designer you'll find the Security page (see Figure 7), which acts as your cockpit for the ClickOnce security model. On this page you can set whether your application will run in Full-Trust (all permissions requested) or in Partial-Trust (some subset of permissions requested). When you choose to run your application in Partial-Trust, you pick the security zone from which your application will be deployed and the desired set of permissions from a checklist of available permissions, with the defaults for the zone indicated.Now the kicker is that when you click F5 after setting up your application permissions on the Security page, the application will run as if it was deployed with the security settings you've indicated. This allows you to explore the various code paths of your application to ensure that no security exception will be thrown when the application is deployed.
- ExceptionHelper. When your application experiences a security exception as a result of running in DIZ mode, the ExceptionHelper will trap the exception and indicate which permission needs to be added so that the CLR will no longer prevent the offending action.
- IntelliSense-In-Zone. At design time when DIZ is enabled in Visual Studio, IntelliSense will only show methods and properties in the dropdown that will run without throwing security exceptions, given the permission set currently requested by your application. Disallowed members will appear grayed out in the dropdown.
|Figure 8: One way to elevate trust for a ClickOnce application is for the user to accept the Trust dialog box displayed at install-time.|
- Calculate Permissions. Accessible from the Security page, Calculate Permissions causes Visual Studio to statically analyze your application's code and recommend a set of permissions that virtually guarantees that you will not get security exceptions at runtime. For this reason, it tends to be overly-conservative; however, it can serve as a starting point for determining the permission set required by your application. You can then use the other tools mentioned above to whittle down to the minimal permission set.
So now you know the security requirements of your application, but in the case that you're exceeding defaults for the zone of deployment, your application will need to be granted elevated trust at install time.
There are two ways this can happen for ClickOnce applications. In the case that there is no administrator in the picture, the decision to elevate trust can be made by the end-user installing the application. At the point when the user executes the installation link, the ClickOnce runtime detects that the application is demanding a non-default permission set. Similar to the Internet Explorer Run/Save dialogs, ClickOnce will prompt the user (see Figure 8), indicating that the application could harm the user's machine. The user has the choice of either granting elevation and proceeding with the install or canceling. In order to minimize annoyance to the user, the trust decision is cached, so he will not be prompted again when he next runs the application. The only exception is if an update being applied demands permissions beyond what was originally requested by the current version of the application; in this case, the ClickOnce runtime will prompt again when the application updates.
The other option is for an administrator to push out policy via IT infrastructure, such as Active Directory. I'll talk about how to do this in a moment, but first I need to talk about signing.