Исключение System.TypeLoadException не обработано / нарушены правила безопасности наследования при переопределении члена - PullRequest
Новая
       26

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

5 голосов
/ 31 января 2012

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

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

System.TypeLoadException не обработано
Сообщение = Нарушение правил безопасности наследования при переопределении элемента: '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).Все еще не повезло ....

Есть идеи ??

Ответы [ 2 ]

6 голосов
/ 31 января 2012

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

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Для получения дополнительной информации о различиях между моделями прозрачности Level1 и Level2 см. http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-rule-sets.aspx.

1 голос
/ 09 августа 2016

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

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

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

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

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

...