Попытка прозрачным для безопасности методом 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 я должен заставить службу использовать устаревшую политику безопасности с помощью следующей конфигурации:

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

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