System.TypeLoadException не было обработано/нарушены правила безопасности наследования при переопределении члена

Можете ли вы создать версию своего приложения .NET 4 для тестирования — таков был невинный вопрос начальства. Конечно!

Но после того, как я изменил наши 27 проектов в нашем приложении Winforms на .NET 4 и перекомпилировал, при запуске приложения я получаю

System.TypeLoadException не было обработано
Message=Нарушены правила безопасности наследования при переопределении члена: 'MyCustomORM.GetObjectData(System.Runtime.Serialization.SerializationInfo, System. Runtime.Serialization.StreamingContext)». Доступность переопределяемого метода с точки зрения безопасности должна соответствовать доступности переопределяемого метода с точки зрения безопасности.

Хм.....

MyCustomORM действительно реализует интерфейс ISerializable и поэтому имеет этот метод

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

и у меня также есть два класса, производных от Exception, которые переопределяют метод GetObjectData.

Но что тут может быть не так?? Погуглив, я нашел несколько дополнительных атрибутов для моего метода и пространства имен, поэтому я сделал:

[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.......
      }
  }
}

но это ничего не меняет.....

Исключение происходит еще до того, как будет достигнута моя первая строка кода в моем методе static Main()....

Я просмотрел проект и удалил все ссылки на старые библиотеки .NET 1.1 (да, приложение такое старое.....) и заменил их их аналогами .NET 4 (в основном log4net). Все равно не повезло....

Любые идеи??


person marc_s    schedule 31.01.2012    source источник
comment
Существует «флаг» для управления этим поведением. Хотя не могу вспомнить, где. Ошибка также указывает на то, что вы не можете использовать там virtual.   -  person leppie    schedule 31.01.2012
comment
Кроме того, GetObjectData на самом деле не имеет смысла в абстрактном классе, поскольку вы никогда не сможете повторно создать его экземпляр (в экземпляр абстрактного типа).   -  person leppie    schedule 31.01.2012


Ответы (2)


Помечена ли сборка, в которой находится класс MyCustomORM, атрибутом SecurityTransparentAttribute? Если это так, проблема связана с изменениями в модели прозрачности безопасности между .NET 3.5 и .NET 4.0. Для вашего тестового сценария вы можете просто выбрать использование старого механизма прозрачности. Для этого добавьте следующий атрибут уровня сборки:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Дополнительные сведения о различиях между моделями прозрачности уровня 1 и уровня 2 см. в разделе http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-наборыправил.aspx.

person Nicole Calinoiu    schedule 31.01.2012
comment
Все сборки, кажется, имеют атрибут [assembly: AllowPartiallyTrustedCallers] - person marc_s; 31.01.2012
comment
В соответствии с правилами уровня 2 APTCA приводит к тому, что весь код в сборке рассматривается как прозрачный, если только он не помечен как критический. Указание правил уровня 1 с помощью SecurityRulesAttribute должно решить вашу непосредственную проблему, как если бы вы использовали SecurityTransparentAttribute. - person Nicole Calinoiu; 31.01.2012

Я знаю, что это довольно старо, но недавно я столкнулся с этой проблемой с одной из моих сборок. Это происходило только на некоторых машинах, и было очень трудно определить, что его вызвало. Я не просто хотел внести коррективы в правила безопасности, поэтому после долгих поисков я наткнулся на инструмент SecAnnotate, входящий в состав Visual Studio.

Использование SecAnnotate для выявления нарушений прозрачности

Используя инструмент, я смог определить, что одна из моих сборок ссылалась на более старую версию dll, которая содержала некоторые атрибуты безопасности, вызывающие проблему. Обновление ссылки устранило проблему.

Инструмент SecAnnotate кажется отличным способом выявления любых нарушений, которые вы могли случайно упустить из виду или о которых не знали.

Надеюсь, это поможет кому-то.

person Ed Downs    schedule 09.08.2016