Select Category
Sitemap Help Contact
print article

Resolving ASP.NET Errors

If you are frequently recieving errors using ASP.NET, use the insturctions below to resolve the error that applies to you.


In a shared hosting environment ASP.NET has been restricted for security reasons to prevent malicious customers spying and manipulating others and their data. These restrictions are based on the .NET feature "Code Access Security" (CAS). In dedicated hosting (e.g. 1&1 Windows Server) these restrictions are not necessary, whereby ASP.NET Code can work with so called FullTrust.

CAS will grant access to only critical resources that hold particular CAS permissions. In shared hosting the following permissions will be given:

  • DnsPermission to perform DNS queries.
  • FileIOPermission to read and write files within application directory.
  • ReflectionPermission to reflect public members of a type, with "NoFlags"
  • SecurityPermission with Execution, ControlThread and ControlPrincipal
  • SqlClientPermission to access SQL Server using classes of System.Data.SqlClient
  • WebPermission to perform HTTP requests, e.g. to use external XML Web Services. (The access must be done using a proxy server on port 3128)

If ASP.NET code tries to access restricted resources or to use restricted functions that require more than the given permissions, an Exception will be raised. In order to receive a detailed error message it may be necessary to set the option "CustomErrors" value to "Off" in "web.config".

Also with detailed error messages it is sometimes not obvious what the real cause is or what changes are required. In any case a CAS error message will be raised as "SecurityException: The application attempted to perform an operation not allowed by the security policy.". The item "Exception Details" will normally refer to the missing permission: "Request for the permission of type XYZ failed".

The item "Stack Trace" will contain a hint on the piece of code that caused the exception, even with a precise line number if available through debug code. Use .NET Framework Documentation to check which CAS Permission the respective code will require. In many cases there will be alternatives like using a relative path within application directory instead of an absolute path.


For many errors in the context of CAS the error message will be terse and even misleading. This applies to functionality of the .NET Framework that will only work in a FullTrust environment, i.e. an environment that does no restrictions at all with CAS permissions. In contrast this functionality is not utilizable in a protected environment. The error messages will be unsatisfying.

The following functionality will not be available in a protected environment:

1. Classes that explicitly demand FullTrust like classes in name spaces "System.Data.OleDb" and "System.Data.Odbc".

2. Pre-installed Assemblies in Global Assembly Cache (GAC), that are not marked with Attribute "AllowPartiallyTrustedCallers", e. g. "System.EnterpriseServices.dll".

3. Custom, uploaded assemblies that carry a "StrongName" but are not marked with Attribute "AllowPartiallyTrustedCallers"

Unfortunately many components of third party vendors or even of Microsoft additions will fall into the latter category, e.g. designer extensions of "ASP.NET Web Matrix".

In case of FullTrust issues the item "Exception Details" will not be helpful and state e.g. "System.Security.SecurityException: Security error". There may be a wrong hint that debugging should be activated although debugging already is active. In many cases the same functionality can be achieved without FullTrust. For e.g. In order to access SQL Server you can use the specialized classes from "System.Data.SqlClient" instead of OleDb and Odbc.

In order to use a component that carries a strong name you can additionally apply the Attribute "AllowPartiallyTrustedCallers" or remove the strong name before compiling your own version.

You can use the .NET Framework tool "secutil.exe" to determine if an Assembly carries a StrongName:

secutil -s [Assembly.dll]
The .NET Framework tool "ildasm.exe" tells you if the Attribute "AllowPartiallyTrustedCallers" has been applied:

ildasm [Assembly.dll]


If an assembly is marked with declarative Security Attribute the author normally wants to express that special CAS permissions are required to use the component without errors. This kind of Attribute can be displayed with .NET Framework tool "permview.exe"
permview /decl [Assembly.dll]

If the stated permissions cannot be granted (see list above) the respective Assembly will not be loaded at all. However the resulting error message is misleading as it points to as special line in global configuration file "machine.config".

"Configuration Error.

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. Source File: machine.config"

The real cause is the declarative Security Attributes. The mere removal of those Attributes followed by recompiling normally won't help as the author probably had his reason to require those permission. That is why additionally the functionality inside the component must be changed to work without the critical permissions.

For additional information, you may want to reference: