System.TypeLoadException was unhandled / Inheritance security rules violated while overriding member

Question

Can you create a .NET 4 version of your app for testing was the bosses' innocent question - sure!

But after I changed our 27 projects in our Winforms application to .NET 4, and recompiled, when launching the app, I get

System.TypeLoadException was unhandled
Message=Inheritance security rules violated while overriding member: 'MyCustomORM.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.

Hmmm.....

MyCustomORM does indeed implement the ISerializable interface and thus has this method

[Serializable]
public abstract class MyCustomORM: IMyCustomORM, ISerializable, ICloneable, ISecurable
{
    public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        // do stuff here.......
    }
}

and I also have two classes that derive from Exception that override the GetObjectData method.

But what could be wrong here?? Googling around I found some additional attributes to stick onto my method and namespace - so I did:

[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
namespace MyApplication.ORM
{
  [Serializable]
  public abstract class MyCustomORM: IMyCustomORM, ISerializable, ICloneable, ISecurable
  {
      [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)]
      public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
      {
          // do stuff here.......
      }
  }
}

but that doesn't change anything.....

The exception happens even before my first line of code in my static Main() method is reached....

I've combed through the project and removed any references to old .NET 1.1 libraries (yes, the app is that old.....) and replaced them with their .NET 4 counterparts (mostly log4net). Still no luck....

Any ideas??

Answer 1

Is the assembly in which the MyCustomORM class resides marked with SecurityTransparentAttribute? If so, the problem stems from changes in the security transparency model between .NET 3.5 and .NET 4.0. For your testing scenario, you may wish to simply opt into using the older transparency mechanism. To do so, add the following assembly-level attribute:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

For more information on the differences between the Level1 and Level2 transparency models, see http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-rule-sets.aspx.

Answer 2

I know this is pretty old, but I ran into this issue with one of my assemblies recently. It only occurred on some machines and was very difficult to determine what was causing it. I didn't just want to put security rule adjustments in, so after much searching I ran across the SecAnnotate tool that is included with Visual Studio.

Using SecAnnotate to Identify Transparency Violations

Using the tool I was able to determine that one of my assemblies was referencing an older version of a dll which contained some security attributes which were causing the problem. Updating the reference fixed the issue.

The SecAnnotate tool seems like a great way to identify any violations that you may have accidentally overlooked or didn't know about.

Hope this helps someone.