Code Access Security for ClickOnce Applications
ClickOnce applications are based on the .NET Framework and are subject to code access security constraints. For this reason, it is important that you understand the implications of code access security and write your ClickOnce applications accordingly.
Code access security is a mechanism in the .NET Framework that helps limit the access that code has to protected resources and operations. You should always configure the code access security permissions for your ClickOnce application to include only those permissions required by your application. Visual Studio provides the tools necessary to determine and configure the permission set for your application.
Default ClickOnce Code Access Security
By default, a ClickOnce application receives Full Trust permissions when it is installed or run on a client computer. While there may be cases where Full Trust permissions are actually necessary, granting Full Trust permissions usually is not a good idea for two important reasons:
An application with Full Trust permissions has unrestricted access to resources such as the file system and the registry, potentially allowing your application (and the end user's system) to be exploited by malicious code.
When an application requires Full Trust permissions, the end user will be prompted to grant permissions to the application; this means that the application is not truly a ClickOnce experience, and the prompt can potentially be confusing to less experienced users.
When installing from removable media such as a CD-ROM, the user is not prompted. In addition, a network administrator can configure network policy so that users are not prompted when installing an application from a trusted source. For more information, see.
For these reasons, you should always modify the code access security permissions for your application to include only those permissions required by your application. Visual Studio provides the tools necessary to determine and configure the permission set for your application.
Configuring Security Permissions
As a general rule, you should always configure your ClickOnce application to request only the code access security permissions that it actually needs. You can configure security permissions on the Security page of the Project Designer.
The Security page in the Project Designer contains an Enable ClickOnce Security Settings check box. When selected, security permission requests are added to the deployment manifest for your application; at install time the user will be prompted to grant permissions if the requested permissions exceed the default permissions for the zone from which the application is deployed. For more information, see.
Applications deployed from different locations are granted different levels of permissions without prompting. For example, when an application is deployed from the Internet, it receives a highly restrictive set of permissions; from a local Intranet, it receives greater permissions; and from a CD-ROM, it receives Full Trust permissions.
As a starting point for configuring permissions, you can select a security zone from the Zone drop-down list on the Security page. If your application will potentially be deployed from more than one zone, you should select the zone with the least permissions. If you want to start with a blank slate and add the permissions needed by your application one at a time, select the Custom zone.
When a zone is selected, the Permissions list is updated to show the default permissions for that zone; included permissions are indicated by a green check. For more information, see.
To further limit permissions, you can select a permission set and modify its properties. For example, if your application needs to display a File Open dialog box, the FileDialogPermission set grants the right to display dialogs. By default, this permission set allows both File Open and File Save dialogs; to modify this you would select the FileDialogPermission set, click the Properties button to open a Permission Settings dialog box, and set the permission to Open Dialog only. For more information, see.
The properties that can be set vary by permission set; not all permission sets have configurable properties.
You can also exclude permission sets that you do not need, or enable permissions that are not part of a zone's default permissions by picking a value from the Setting drop-down list for the permission set. Permissions that have been modified are denoted by bold text; if a permission has been enabled and it is not part of the zone default, an information icon is added next to the Included check mark.
Enabling permissions that are not part of a zone default will cause the end user to be prompted as noted above. When enabling additional permissions, you should always modify the permission set to include only the permissions that you actually need.
Determining the Permissions Required for an Application
In order to effectively configure security permissions, it helps to know exactly which permissions your application requires. You can use the Permission Calculator tool, accessible from the Security page, to analyze your code and determine the exact permissions required by your application.
There are some limitations to the Permission Calculator tool. The tool performs a static analysis of the code and cannot determine permissions required for late-bound code or for dynamically loaded assemblies. In addition, if you have designed your application to dynamically modify its permission demands when running in an environment with lesser permissions, the tool will report the maximum required permissions.
Once the tool has analyzed your application, all required permission sets will be set to Enabled and marked in bold text; if an enabled permission is not part of the zone default, it will be marked with a warning icon as well. If you want to prevent the end user from being prompted, you should review these and see if there is a way to modify your code so that the permission is no longer required.
For more information, see.
Debugging an Application with Restricted Permissions
As a developer, you most likely are running your development computer with Full Trust permissions, so you will not see the same security exceptions when debugging the application that the end user may see when running it with restricted permissions.
In order to catch these exceptions, you need to debug the application with the same permissions as the end user. Debugging with restricted permissions can be enabled on the Security page of the Project Designer.
When debugging with restricted permissions, exceptions will be raised for any code security demands that have not been enabled on the Security page. An exception helper will appear, providing suggestions on modifying your code to prevent the exception.
In addition, when writing code, the Intellisense feature in the Code Editor will gray out any members that are not included in the security permissions that you have configured.
For more information, see.