Попытка прозрачного для безопасности метода X получить доступ к критическому методу безопасности Y не удалась

У меня достаточно стабильная версия серверного приложения, которая была развернута почти год у десятков клиентов.

Один новый клиент недавно установил приложение и получает следующую ошибку:

System.MethodAccessException: Attempt by security transparent method [SomeMethod] to access security critical method [SomeOtherMethod] failed.

Как SomeMethod, так и SomeOtherMethod - это методы в сборках, которые я написал, которые созданы на основе .NET 4 и работают внутри службы Windows. Если это имеет значение, SomeOtherMethod ссылается на тип из сторонней сборки (EntLib 4.1), созданной для .NET 2.0. Глядя на код для EntLib 4.1, я вижу, что они используют атрибуты SecurityTransparent и APTC, но это никогда не вызывало проблем на других клиентах.

Эти сборки были обновлены с .NET 2.0 CLR, но давно. Этот точный код отлично работает на других клиентах, и я явно не использую атрибут APTC, и нигде не использую атрибут SecurityCritical.

Это приводит меня к выводу, что это проблема конфигурации или, возможно, проблема с патчем .NET Framework. Был ли выпущен патч для .NET, который вызвал бы это критическое изменение? Есть ли какой-нибудь параметр конфигурации, в котором этот тип проверки применяется по умолчанию, но мой клиент мог включить его?

Последний пункт. Мой сервис использует SSRS RDLC для создания PDF-файлов. Из-за некоторых изменений в .NET 4 я должен заставить службу использовать устаревшую политику безопасности через следующую конфигурацию:

  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true" />
  </runtime>

Для получения более подробной информации о том, почему мне нужно это сделать, см. Этот пост stackoverflow:Очень высокое использование памяти в .NET 4.0

Важным моментом является то, что я делаю это на всех других моих клиентов. Только у этого клиента есть проблемы.

Ответы на вопрос(4)

Ваш ответ на вопрос