• Choose a category
• All
• Classic-Fiction

traceMode

Indicates the criteria by which trace records are to be sorted and displayed. Acceptable values are SortByTime (the default) or SortByCategory. Sorting by time means that records are displayed in the order in which they are generated. A category, on the other hand, is a user-defined name that can be optionally specified in the trace text.

writeToDiagnosticsTrace

This is false by default. It specifies whether trace messages should be forwarded to the diagnostics tracing infrastructure, for any registered listeners.

In the .NET Framework, tracing is provided through a unified, abstract API that uses ad hoc drivers to physically output the messages. These drivers are called listeners and redirect the tracing output to the specified target—typically a log file or an output stream. Listeners are defined in the section. When writeToDiagnosticsTrace is true, any ASP.NET-generated trace message is also forwarded to all registered listeners.

The Section

The section configures the trust level under which the application will be run and determines the code-access security (CAS) restrictions applied to the application. By default, all ASP.NET applications run on the Web server as fully trusted applications and are allowed to do whatever their account is allowed to do. The CLR doesn’t sandbox the code. Hence, any security restrictions applied to an application (for example, the inability to write files or write to the registry) are not the sign of partial trust but simply the effect of the underprivileged account under which ASP.NET applications normally run. Here’s the schema for the section:

hostSecurityPolicyResolverType ="security policy resolution type"

legacyCasModel = "[True|False]"

level="[Full|High|Medium|Low|Minimal]"

originUrl="URL"

permissionSetName = "name of the permission set"

processRequestInApplicationTrust = "[True|False]"

/>

You act on the section if you want to run a Web application with less than full trust. The following code snippet shows the default setting in the site root web.config:

Allowable values for the level attribute are all the entries defined in the section.

The originUrl attribute is a sort of misnomer. If you set it, what really happens is quite simple: the application is granted the permission of accessing the specified URL over HTTP using either a Socket or WebRequest class. Of course, the Web permission is granted only if the specified level supports that. Medium and higher trust levels do.

The section supports a Boolean attribute named processRequestInApplicationTrust. If true (the default), the attribute dictates that page requests are automatically restricted to the permissions in the trust policy file applied to the application. If it’s false, there’s the possibility that a page request runs with higher privileges than set in the trust policy.

Note

The section is allowed only at the machine level and application level because of technical reasons, not because of security concerns. An ASP.NET application runs in its own AppDomain, and the trust level for that application is set by applying the appropriate security policy to the AppDomain. Although policy statements can target specific pieces of code, the AppDomain is the lowest level at which a security policy can be applied. If the CLR has a policy level more granular than the AppDomain, you can define different trust levels for various portions of the ASP.NET application.

The following script shows how to specify Medium trust-level settings for all applications on a server. The script is excerpted from a site’s root web.config file. With allowOverride set to false, the trust level is locked and cannot be modified by the application’s root web.config file.