Limitations When Using Partial Trust

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

There may be some limitations regarding how you use partial trust with an Enterprise Library application block. These limitations include the following:

  • Enterprise Library throws a Security Exception if it cannot obtain the mandatory permissions.
  • Some calls to Logging Application Block trace listener classes fail.
  • ASP.NET application directories require specific permissions.
  • The AzMan provider is not available with partial trust.

Enterprise Library Throws Security Exception

If your application cannot obtain the necessary permissions to use a particular Enterprise Library feature, the Enterprise Library typically throws a SecurityException back to the application. The only time this does not happen is when the code that requires the permissions is not seen as critical to the feature's operation. For example, if the Logging Application Block is unable to call the API that provides information about the current process, this information is simply left out of the logged message and the call succeeds.

Limitations on Logging Application Block Trace Listeners

Creating an event log and creating a directory for a disk file both require full trust. Therefore, the Logging Application Block listeners fail when they attempt these actions while running under partial trust. The following two of the classes in the Logging Application Block cause a load failure even if you do not use them in your code because the Enterprise Library initializes and caches them:

  • FormattedTextWriterTraceListener. This class checks whether the specified directory exists in its constructor and creates the directory if it does not exist. However, the Directory.Exists method that it uses returns false under partial trust if the FileIOPermission class with the appropriate permissions for the target directory have not been added to the custom policy file. This prevents the application block from creating a LogWriter object if the trace listener is configured in the application configuration file. This occurs even if you do not use the FormattedTextWriterTraceListener class in your application.

For all other listeners that are configured in the application configuration file, including the TextWriterTraceListener class, the code fails only when the code calls the TraceData method to access a listener.

ASP.NET Application Directories Require Permissions

By default, ASP.NET runs under the ASPNET account in Windows 2000 and Windows XP; it runs under the NetworkService account in Windows Server 2003 and later. If you specify a FileConfigurationSource object that is located in a directory outside the ASP.NET application folders, the account under which the application is running must have the correct permissions. The following procedure describes how to set these permissions.

To set permissions for ASP.NET application directories

  1. Add the FileIOPermission class to the policy file's <SecurityClasses> element.
  2. Set the Read and PathDiscovery attributes to the file specified in the Enterprise Library FileConfigurationSource class.
  3. Set the Read and Execute ACL permissions to the file specified in the FileConfigurationSource class.

AzMan Provider Not Available

The AzMan provider requires the Enterprise Library to be fully trusted. Because Enterprise Library does not support partially trusted calls to trusted assemblies, any application that uses the AzMan provider in the Enterprise Library must also be fully trusted. You cannot use the AzMan provider with a partial-trust security level.