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.

Creating an event log requires Administrator privileges at the operating system level and EventLogPermission with Administer access at the code access security level. You must have the appropriate access control lists (ACLs) and FileIO certificate authority permissions to create folders and files.

Therefore, the Logging Application Block listeners cause a load failure when they attempt these actions while running under partial trust.

Note:
The load failure is not an assembly load failure.

The following two 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 the configured trace listeners and does not dispose of them until the application is closed:

• 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.
• RollingFlatFileTraceListener. This class has the same requirements as the FormattedTextWriterTraceListener class.

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

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.

The AzMan provider requires the Enterprise Library to be fully trusted. Trusted assemblies must opt in to accept partially trusted callers, which affects only the direct caller. However, the SecurityTransparent attribute in Enterprise Library makes the LinkDemands into FullDemands, thus requiring the application to be fully trusted before invoking the methods on the trusted assembly through Enterprise Library. Any application that uses the AzMan provider in the Enterprise Library must also be fully trusted. You cannot use the AzMan provider with partial trust.

For more information see Partial Trust Environments.