Inheritance security rules violated while overriding member - SecurityRuleSet.Level2
I have a class that inherits from Exception. In .NET 4, I started receiving a runtime error:
Inheritance security rules violated while overriding member: MyBusinessException.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden.
I think the issue is caused by the fact that I am overriding GetObjectData.
I know one answer for resolving the issue is to set the SecurityRuleSet:
[assembly: SecurityRules(SecurityRuleSet.Level1)]
This is not an acceptable answer, I'd like to know how to fix the issue without having to relax the default security rules in .NET 4.
Mark GetObjectData
with SecurityCriticalAttribute
, because it's applied to Exception.GetObjectData
. An overridden member should have the same security accessibility (Critical, Safe Critical or Transparent).
Read Security Changes in the .NET Framework 4 and Security Transparent Code, Level 2 from MSDN for more information.
To avoid all potential security runtime exceptions, enable Code Analysis with the Security rule set. You'll get static analysis warnings that might correspond to runtime errors.
Had this problem when I was calling an assembly that had AllowPartiallyTrustedCallers attribute:
[assembly: System.Security.AllowPartiallyTrustedCallers]
Removing it solved my problem without switching to SecurityRuleSet.Level1.
Regarding this error in shared hosting environments that allow full trust applications. When you bin deploy an application, you often overwrite web.config. Under IIS, when you change the trust settings to something different than the default, your web config section is modified with:
<system.web>
<trust level="Full" />
<system.web>
Copying a new web.config during deployment often overwrites this setting, however IIS Admin will still show the site as "Full Trust", when in reality the site is running in whatever the default trust level is for your shared host provider (usually medium).
You'll see this error and do what I did - try to figure out why you would see it even though you know the site is running under full trust, when in actuality, it is not. The solution is either to modify your web config as noted above before deployment, or use IIS Admin to set the site to a different trust level (high, for instance), apply it, then set it back to full. Doing so reinserts the necessary config file information and restarts the application pool in full trust.