Попытка прозрачного для безопасности метода 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
Важным моментом является то, что я делаю это на всех других моих клиентов. Только у этого клиента есть проблемы.