Вы правы: в .NET 4, оставляя APTCA включенной, вы делаете сборку SecurityTransparent, и это может вызвать у вас горе.
В статье MSDN Миграция сборки APTCA в .NET Framework 4 содержится хорошее обсуждение и объяснение изменений в атрибуте AllowPartiallyTrustedCallers в .NET 4.
В частности:
Атрибут AllowPartiallyTrustedCallers был изменен. В версии 4 он больше не связан с требованиями к ссылкам. Фактически, неявное требование ссылки, которое присутствовало в подписанных библиотеках в v2, исчезло. Вместо этого все полностью доверенные сборки в v4 по умолчанию являются SecurityCritical.
[snip /]
В v4 эффект APTCA заключается в удалении автоматического поведения SecurityCritical из сборки, к которой оно применено.
И ...
Поскольку атрибут AllowPartiallyTrustedCallers по умолчанию заставляет всю сборку быть SecurityTransparent, автор сборки должен специально пометить методы, необходимые для выполнения привилегированных операций, как SecurityCritical или SecuritySafeCritical.
(Это действительно хорошая статья, с которой автор Майк Русос отлично поработал. Я призываю вас прочитать ее полностью. )
Если вы запускаете новую библиотеку .NET 4, вероятно, лучше придерживаться модели безопасности .NET 4 и использовать соответствующие атрибуты SecurityCritical, SecuritySafeCritical и SecurityTransparent, где это необходимо. Они гораздо проще в управлении и понимании, чем старый код доступа к безопасности.
Если вы переносите старую библиотеку на новую модель, в статье есть хороший пример того, как это сделать ... но в основном это сводится к удалению старых LinkDemands и добавлению [SecurityCritical] вместо них.
В вашем конкретном случае, самый быстрый способ состоит в том, чтобы добавить атрибут SecurityRules, чтобы вы получили старое поведение, но я не уверен, что считаю правильным способ. Возможно, правильным способом было бы потерять APTCA и добавить SecurityCritical в сборку , поскольку сборка может содержать код SecurityCritical , а затем пометить различные типы, вызывающие код SecurityCritical (например, материал, ссылающийся на GetObjectData), с помощью SecuritySafeCritical, так что Ваш SecurityTransparent код может вызвать его. Конечно, этот второй подход будет намного больше работы, поэтому вы, вероятно, захотите запустить SecAnnotate.exe и получить несколько автоматических советов.
Глядя на магистраль Moq, поиск GetObjectData показывает, что рассматриваемый метод является переопределением для механизма сериализации исключений (ISerializable.GetObjectData для System.Exception), который в любом случае будет вызывать только код SecurityCritical, так что вы не можете даже столкнуться с любой проблемой, если вы просто потеряете APTCA и отметите сборку SecurityCritical.
Существует проблема, поданная в Autofac для обновления ее до последней модели безопасности. Если вам понравилась идея, отправьте ее на голосование / комментарий.
Извините, это не был короткий ответ. Безопасность, к сожалению, никогда не бывает легкой. : S