New Security Exception Handling in Whidbey

Security exceptions are one of the harder exceptions to debug, primarily due to the lack of useful information. In Whidbey, the System.Security.SecurityException has been enhanced to include information that can be used to determine not only the cause of the failure but which method was being called, what zone the code was executing in, and specifically which assembly caused the failure.

Since most developers build and unit test their code in a fully trusted environment, many security errors go unnoticed until the code is deployed into a testing or production environment. This makes having accurate and complete security exception information very important and has been a major failing of the security exception handling in .NET versions 1.0 and 1.1. Whidbey will address this by adding the following information to the security exception type.

Action - the SecurityAction that failed the security check
Demanded - the permission, permission set, or permission sets that were demanded and triggered the exception
DenySetInstance - if a Deny stack frame caused the security exception to fail, then this property will contain that set, otherwise it will be null.
FailedAssemblyInfo - AssemblyName of the assembly that caused the security check to fail
FirstPermissionThatFailed - the first permission in failing PermissionSet (or PermissionSetCollection) that did not pass the security check
Method - the method that the failed assembly was in when it encountered the security check that triggered the exception. If a PermitOnly or Deny stack frame failed, this will contain the method that put the PermitOnly or Deny frame on the stack.
PermitOnlySetInstance - if the stack frame that caused that caused the security exception had a PermitOnly permission set, this property will contain it, otherwise it will be null
Url - URL of the assembly that failed the security check
Zone - Zone of the assembly that failed the security check.